[Build 14] – Keynote day 2

Mail de Alexandru
Jeudi 3 avril 2014 16:42

Keynote day 2

Motto: Mobile first, cloud first.
// Intro

Three hundred new features in 2013, 44 new features presented now. New Azure regions in China (continental). Adoption of azure, growing:
– 57% Fortune 500, 250K websites, 1.000.000 SQL Databases, 200 trillion storage objects, 300 Mio AD users, 1Mio VS Online.
Titanfall (game) is presented, demo & interview with the team. The general lack of lag is highlighted = everyone has the same frame rate, the game does not depend on the local available power. Game cannot be played without the cloud. More 100.000 VM on launch day.
Another experience with Azure: 2014 Sochi Olympics with NBC. 100 Mio users, 2.1Mio concurrent HD viewers during US/Canada hockey match.
Rick Cordella (sr VP and General Mgr NBC Sports digital) does a testimony concerning the impact of the cloud on his news channel. 1Bio dollars invested, 70 days to recover the investment. “There is no going back”.
Azure : Internet as a Service (IaaS) Or PaaS (Platform as a service).
// IaaS

New features:
– Virtual Studio integration (create, manage, destroy or debug VM) without leaving it.
– Capture VM images with any number of storage drives=> create any instances as necessary.
– Puppet modules (sql, web, app). Chef server is presented. Puppet Master manages puppets (change VM role, etc.).

Integration with VS
Demo with VS @ creating a VM, based on OS, etc, all from the VS Server Explorer. A nice wizard (OS, ports, etc.). Debug is possible & demoed (right click on the vm => enable debug). The debugging client is injected in the VM. Attach the debugger => all works (frenetic applause in the room….)

Command List is demoed, launching powershell commands. A “snapshot” capability is possible with this command option. Disks are copied on the fly.

“Puppet Master” is demoed (partnership with Puppet Labs partner). “Puppet master server” linking is demoed. Puppet CEO showcases the technology.
“Puppet Class” => demo for deploying technology (sysinternals for ex, deployed on all the machines).
The object of their techno is to install & synchronize machines fast: automate configuration management.
“Getty Images” testimony is next. Hint: non-commercial service launched.
Scott takes over again: new features listed (see photo)
// PaaS

PaaS is the detailed (prebuilt services). Patching, load balancing, etc is handled.
Capabilities are presented in detail.

Azure Website service
Deploy web applications. Java is supported, etc.
– Autoscale is by default, maximum number of VM (& the minimum) is customizable.
– Staging (test facilities for example) is presented. Swap function allows an easy deployment.
– Webjobs is for background tasks that should relief the load from a webserver. A queue is the typical example. Same machine can be used as the azure web site
– Traffic Manager support. Single DNS entry, with instances all around the world. You can route your traffic based on geographical location. Not for VM only, but for websites also.
Mads Kristensen (Web in action) is next.
Creating a website & database from VS. Publishing scripts are created (can be modified). Browser Developer Tools demoed with live modification of the background (=> VS changes also). See the transcript from yesterday 3-602. JsHint is demoed. Staging feature is presented. *-staging.azurewebsites.net suffix. Swap feature demoed (with certificates, etc.). Background task are demoed via WebJobs. Same context is used. The “invocation log” can be seen in order to monitor the Webjob. Traffic Manager scenarios are presented (failover, performance, etc.).

Web announcements
are listed (see photo).
MVC 5.1, Web API 2.1, Identity 2.0, etc.

Mobile Services
– Develop backends with .net, node.js.
– Flexible data (No SQL, SQL, blob storage, etc.)
– Broadcast notifications. Notification hubs => broadcast afterwards
– Now supports Active Directory (new). Standard OAuth tokens => custom logic possible (for ex Office). Works with any device (Android, iOS, etc.)
Demo for Mobile Services is next. API Documentation & a Test Client. Local & Remote Debug demoed. Template for a Controller & Security is demoed. Portable Class Library is used. Native Authentication Library demoed (Active Directory). SharePoint or Office 365 integration is demoed, quite nice demo. Xamarin integration & demoed on iOS. Nice cross platform demo.

Enterprise Auth & Office 365 API
Demo & testimony by DocuSign, Grant Peterson (CTO). Active Directory integration gets demoed, on an iPhone. SharePoint integration is also demoed (still on the iPhone). Signing on the run possible, nice demo! 20 lines of code in Objective C on the iPhone & that’s it.
Mobile announcements (see photo)
Azure AD SDK for android & iOs, Office 365, Azure AD premium, SSO AD, Notifications on Kindle, etc.

Data is the next chapter
SQL Improvements in Azure \
– Size 150Gb-> 500Gb, 99.95% SLA.
– Self service restore. Automatic backups possible. Restore a snapshot.
– Active geo replication (primary instance-> data replication-> readonly secondary region). Multiple centers in the same region (Europe for ex).
– Other announcements listed (see photo).


// Next is programming languages & tools for Azure

New .NET compiler platform (Roslyn) is highlighted. Anders Hejlsberg is talking over the show.
New generation preview: VSIX available. Features
– Importing static (Math.PI for example), Math.PI gets Pi directly (using System.Math needs to be added).
– Rename help
– OPEN SOURCE Roslyn project. It is on Codeplex! Publish LIVE. .NET compiler goes Open Source…
– Modification on the compiler shown (changing quotes for example)
Migel de ICAZA (Xamarin) does the next demo. He changes the IDE from Mono-> Roslyn, compiles, works.
Scott takes over:
Announcing the .NET Foundation, founding project shown on photo (see photo).
// New Azure Management Portal

The new Azure Management Portal is demoed: Bill Staples. Looks like a W8 app., Blade is the term used for the dropdown that allows a drilldown (see photo). A new navigation method (journey) on the website.
The billing can be drilled down more effectively. Resource costs are easily available.
The portal is open, third party devs can integrate with it.
Continous deployment is presented directly from the Azure Portal. Seamless switching between Visual Studio & Azure is demoed. Commit can be seen on the portal directly (code view level…).
AppInsights integrated with the Azure Portal. You can edit the code directly on the Portal!
Personal comment: the blade feature is a little bit confusing…
Analytics is integrated on the new Azure Portal. Avg response time, availability, etc.
Scale up a website is now possible, without redeployment (Lionel sera content)
Demo on a desktop (an enormous touchscreen TV is shown)
Entire lifecycle: starting the service, coding, command line, analytics, management, etc.
Personal comment: the investment in this portal was huge I believe => Microsoft is placing its bets

– Azure Portal preview
– Azure Resource Manager preview
– VS online General Audience


Les jointures en SQL

Voici un post qui explique les différentes types de jointures dans les requêtes sql.

Partons d’une structure de base de données suivante :



La jointure INNER JOIN

Elle retourne l’intersection entre ces 2 tables

SELECT Table1.*,Table2.*
FROM Table1
INNER JOIN Table2 ON Table1.ID = Table2.ID

Cette requête renvoie comme résultats

La jointure OUTER JOIN

Il existe différentes méthode des jointures outer join


Cette jointure retourne tous les enregistrements qui se trouvent dans la table de gauche de la jointure.

Et si l’enregistrement n’est pas présent dans la table de droite, le résultat renvoie NULL pour cette partie.

SELECT Table1.*,Table2.*
FROM Table1
LEFT OUTER JOIN Table2 ON Table1.ID = Table2.ID

Le résultat de cette requête renvoie


Cette jointure retourne tous les enregistrements qui se trouvent dans la table de droite de la jointure.

Et si l’enregistrement n’est pas présent dans la table de gauche, le résultat renvoie NULL pour cette partie.

SELECT Table1.*,Table2.*
FROM Table1
RIGHT OUTER JOIN Table2 ON Table1.ID = Table2.ID

Le résultat de cette requête renvoie


Cette jointure retourne tous les enregistrements qui se trouvent dans les 2 tables de la jointure.

Et si un enregistrement n’a pas de correspondance dans l’autre table, le résultat renvoie NULL pour celui ci.

SELECT Table1.*,Table2.*
FROM Table1
FULL OUTER JOIN Table2 ON Table1.ID = Table2.ID

Le résultat de cette requête renvoie

La jointure CROSS JOIN

Cette jointure fait le produit cartésien entre les 2 tables.

Chaque ligne est multipliée avec celles de l’autre table.

SELECT Table1.*,Table2.*
FROM Table1

Voici une partie des résultats de la requête :


Pour plus d’informations:



[SPC14] The nuts and bolts of upgrading to SharePoint 2013

Mail deFabien

Session par Shane Young et Todd Klindt / Rackspace

// Résumé

Un rappel en démo de d’upgrade depuis SharePoint 2010 vers 2013 en attachant la BDD.

// méthode d’upgrade

En 2007: gradual, DB attach, in-place
En 2013 : que DB attach

Les bases que l’ont peut upgrader: bcs, managed méta, performance point, secure store, user profile, search administration

Pour la recherche, il y a des chances que l’on fasse mieux de repartir de zéro et tout reindexer.

A savoir: upgrade d’abord les bases avec les site collection racines, essayer de garder les mêmes url, ajouter les manager paths manuellement avant d’attacher les bases.
Penser qu’il faut plus de hardware! (serveur de recherche dédié dans la plupart des cas, osa, etc…)

// authentification

En 2013, on doit utiliser claims.

2 méthodes :
• Faire d’upgrade dans SP2010
• Ou dans 2013
Les deux fonctionnent mais il préconise la deuxième car cela évite de faire la manipulation sur le serveur 2010 qui doit être celui de production.

Une bonne pratique quand on migre de 2007 a 2013 est d’installer le sp2010 sur la même Instance SQL que 2013, cela évite de copier les données entre les SQL.

// upgrade check

L’outil preupgradecheck n’existe plus.
A la place, on peut utiliser test-spcontentdatabase
Il y a un paramètre showLocation à mettre pour avoir les détails s’il trouve des problèmes.

// feature et solutions

Les customisation 2010 fonctionnent. A condition que c’était dans des wsp !
Un script pour exporter les wsp:
Il y a aussi un projet codeplex: feature explorer pour nous aider
Mais c’est bien de se poser la question : dois je bien le migrer ? 😉

// upgrade d’une base

Test-spcontentdatabase ….
Mount-spcontentdatabase …

// démo

Il restore une base 2010 sur son instance SQL utilisée pour 2013.

Ensuite en powershell, il démarre Start-transcript, puis :
• test-spcontentdatabase, il lui manque un fichier dwp , non blocking, pas grave… GO!
• Mount-spcontentdatabase.
Un log est créé dans les logs SharePoint.
Le « Mount » est très long, il consomme beaucoup d’IO, prévoir des disques rapides 😛

C’est bon, on a le site mais l’expérience est restée comme en 2010, avec en plus, le bandeau qui propose d’upgrade la collection.
Ca se fait dans les site collection settings, on commence par le ‘site collection health check’, puis on upgrade la collection.
(attention, Il est bon de tester sur une site collection de test. 🙂 )
L’upgrade est immédiat ou est fait pendant la nuit via un job, ca dépend du travail, SharePoint planifie pour nous.


Gestion des rôles avec Analyses Services (SSAS)

Cet article a pour but de présenter les différentes phases de la mise en place des droits d’accès aux dimensions et aux mesures d’un cube. Ceci en fonction du rôle et de la place occupée dans l’entreprise.

Cas d’étude :




Schéma technique de la solution :


Besoin :

La Direction Générale a fait la demande suivante au service décisionnel:

v  Pour la division COMMERCIALE

  • Afficher la mesure Budget Euros
  • Masquer les mesures Budget Effectif et Effectif Disponible (de la division uniquement)

v  Pour La Division RH

  • Accès aux mesures Budget Effectif et Effectif Disponible de l’entreprise


 Conseil :

Utiliser des noms explicites pour les rôles afin de cibler le périmètre et les droits d’accès des membres de ce rôle.
Administrer les droits d’accès au niveau du domaine.

Solution technique :

Créer pour  chaque division un GROUPE dans l’Active Directory.
Ces groupes serviront à restreindre l’accès aux données par division.

Récapitulatif :


En  pratique lorsqu’un utilisateur appartient à plusieurs rôles, ces rôles se complètent.

Le rôle administrateur est en règle générale appliqué aux DBAs de l’entreprise.
Le rôle lecteur peut être attribué aux développeurs de la solution et ou aux Power Users.




Ouvrir le projet SSAS dans Visual Studio.
Sous l’onglet Role de votre projet SSAS, faire un clic-droit, New Role :


Première étape, on va créer le Role Admin.
On définit le nom du rôle et les autorisations attribuées aux membres du groupe sur le cube en cochant les cases Full Control, Process Database, Read definition dans l’onglet général :Snap5

Sous l’onglet Membership, cliquer sur le bouton Add pour rechercher dans l’Active Directory le groupe ADMINISTRATORS :


Deuxième étape, on passe à la création du rôle lecteur dont les membres seront les personnes habilitées à voir toutes les mesures du cube sans exception :


Au niveau de l’onglet Data Sources, cocher la case Read Definition et laisser  la colonne Acces à None.


L’accès se fait en lecture (Read).
La colonne Local Cube/drillthrough Access à None pour interdire le rapatriement du cube en local.
La case Process est décochée afin d’interdire le traitement du cube.


3eme étape :

Même procédé que lors de l’étape précédente.
Nous allons détailler dans notre exemple la création du rôle  dont le nom sera «  RoleCommerce ».

Sous l’onglet Cell Data, sélectionner le cube résultat, puis cocher la case Enable  read-contingent permissions.

La requête à taper en MDX correspondante est:
(NOT [Measures].CurrentMember IS [Measures].[Effectif Disponible]) AND(NOT[Measures].CurrentMember IS [Measures].[Effectif Budget])


Par défaut, dans l’onglet dimensions, cocher les cases Read Definition afin que les dimensions soient accessibles  en lecture. Dans un second temps, nous allons rendre visible uniquement le code et le libellé de la division 54195 de la Dimension Division pour le rôle concerné (COMMERCE)

Sous l’onglet Dimension Data -> Attribute : déplier le cube Résultat et sélectionner la dimension cube (Dim Division) La dimension division dont le code de division commerciale est 54195.

Deux modes disponibles, un mode Basic (graphique) et un mode Avancé (code MDX) :


Après déploiement et traitement du cube, via SSMS ou Visual Studio, repérer le bouton qui permet de choisir l’utilisateur se connectant au cube :


Sélectionner le rôle à tester (COMMERCE dans notre cas), puis cliquer sur OK :


En glissant,  la mesure Effectif Disponible, Budget Effectif et Budget Euros :


Constats et Résultats :
Les cellules relatives aux mesures Effectif Disponible et Effectif Budget sont indisponibles (#N/A).
La mesure Budget Euros est visible pour les membres de la division concernée.
Un dernier détail qui a son importance, le Grand Total de cette mesure ne doit pas faire apparaître le budget des autres divisions. Pour cela, il faut cocher la case Enable Visual Totals dans l’onglet Dimension Data du rôle  :


Pour aller plus loin :

Microsoft SQL SERVER 2008 Ebook Analyses Services Step by Step (free e-book)

Focus sur SQL CE for Windows Phone


Avec le déploiement de Windows Phone 7.5 (Mango), une nouvelle fonctionnalité très attendue est venue enrichir l’environnement de développement sur Windows Phone 7 : la base de données locale.

Depuis son lancement, de nombreux développeurs se sont heurtés à des problèmes de performance en utilisant cette version de SQL Compact Edition spécialement dédiée à Windows Phone.

Cet article vise à rassembler et à organiser un certain nombre d’astuces et de bonnes pratiques glanées sur internet dans le but de tirer le meilleur de cette base en terme de performance.

Bref historique de SQL Compact Edition for Windows Phone

Initialement disponible et éprouvé sur Windows mobile 6.5 , SQL CE Mobile brillait par son absence sur Windows Phone 7.

Plusieurs raisons pouvaient expliquer une telle situation :

  • Véritable volonté de réduire au maximum le stockage de grande quantité de données sur le téléphone au profit de synchronisation avec serveur distants?
  • Manque de temps à l’issue du gigantesque chantier qui a mené MS à concevoir Windows Phone 7 en un peu plus d’un an seulement?

Quelles qu’en soient les raisons, le besoin s’est rapidement fait sentir pour le développement d’applications en tout genre et la communauté de développeurs Windows Phone s’est rapidement mobilisée pour proposer des solutions.

En voici une liste non exhaustives :

La mise à disposition de SQL CE for Windows Phone a sonné le glas de bon nombre de ces projets. En effet, l’intérêt de solutions managées semblent limité face à ce port natif de SQL CE 3.5 spécialement conçu pour Windows Phone et officiel qui plus est.

Des alternatives sur Windows Phone 7?

Pour autant et à l’image de Sterling, les développements et la popularisation de certains projets se sont poursuivis car ils se sont démarqués pour des usages bien particuliers.

Sterling avec son orientation NoSQL et le soin tout particulier apporté à l’optimisation des opérations de sérialisation / désérialisation se distingue par exemple par sa simplicité d’utilisation et ses performances en lecture.

Néanmoins sur Windows Phone 7 et parmi les solutions existantes, SQL CE de par son implémentation native parait être le choix le plus adapté lorsqu’il s’agit de travailler sur de grande quantité de données à la fois en lecture et en écriture.

Pour une comparaison entre SQL CE for Windows Phone et Sterling, rendez vous à cette adresse.

Astuces et bonnes pratiques générales

Gardez un œil sur les requêtes soumises à la base

L’une des première surprise rencontrée lors de l’utilisation de SQL CE for Windows Phone est que l’exécution directe de Transact-SQL n’est pas supporté.

Le recours à LINQ to SQL sur Windows Phone est donc obligatoire pour communiquer avec sa base de données locale relationnelle. Ce dernier a la responsabilité de traduire les requêtes de LINQ vers Transact-SQL et de matérialiser les résultats retournés par la base.

Pour éviter l’effet boîte noire, il est possible de logger les requêtes générées par LINQ to SQL et soumises à la base.

Pour ce faire, tout se joue au niveau de l’objet DataContext qui comporte une propriété Log. Si cette dernière est affectée à un StreamWriter, toute l’activité du DataContext concerné sera loggée par son intermédiaire.

using (var context = new MyDataContext(MyDataContext.DBConnectionString))
using (context.Log = new StreamWriter(IsolatedStorageFile.GetUserStoreForApplication().CreateFile("logs.txt")))
    // Ecrivez ici les insert, update, delete dont vous avez besoin...

Il ne vous reste plus qu’à récupérer le fichier de log de votre émulateur ou téléphone vers votre PC à l’aide d’outils de développement spécifiques tels que IsoStorageSpy ou encore Windows Phone Power Tools.

Chiffrez votre base dégrade les performances

SQL CE for Windows Phone supporte le chiffrement des données contenues, il vous suffit d’ajouter le paramètre Password dans votre connection string. Mais n’oubliez pas que cette sécurité a un prix en terme de performance : des opérations supplémentaires de chiffrement et déchiffrement viendront respectivement s’ajouter à chaque opération d’écriture et de lecture en base.

Maitrisez la durée de vie de votre DataContext

Pour faire face aux problèmes de performance rencontrés avec SQL CE for Windows Phone, le DataContext présente un atout majeur  : son cache.  Les résultats des requêtes effectuées avec un DataContext donné sont conservés et réutilisés par la suite pour limiter les allers et retours avec la base. Ce mécanisme permet ainsi d’accélérer les prochaines requêtes pointant sur des données déjà chargées en mémoire.  Pour résumer, plus le cache de votre DataContext contient d’objets, plus les chances sont grandes pour que les données que vous souhaitez obtenir soient déjà chargées en mémoire, plus les résultats vous seront retournés rapidement.  Afin de tirer parti au maximum de ce cache, la tentation est donc grande de ne créer qu’une seule instance de DataContext pour l’ensemble de votre application.
Cependant, il peut être intéressant de rappeler certaines contraintes qui s’appliquent à notre cher DataContext :
  • Votre application Windows Phone 7 ne peut occuper plus de 90 mo en mémoire. A cause de son cache, votre instance de DataContext pourrait bien dépasser ce quota si vous n’y prenez pas garde.
  • Une instance de DataContext n’est pas thread-safe, les accès concurrents produisent une InvalidOperationException. En revanche, SQL CE supporte les accès concurrents de plusieurs DataContexts différents.
Ces limitations ne plaident pas en faveur d’une instance de DataContext unique. Les pistes plus pérennes pourraient être les suivantes :
  • Suivre les bonnes pratiques LINQ to SQL et Entity Framework : Regroupez et encapsulez les accès à la base dans des classes et des méthodes dédiées en fonction de vos besoins techniques et/ou fonctionnels. Instanciez et détruisez un nouveau DataContext dans chaque méthode (avec un using), ils sont conçus pour avoir une durée de vie assez courte. Pour plus d’informations, voir ici.
  • Définir des instances de DataContext pour des usages bien spécifiques et garantir un accès synchronisé à chacune d’entre elle.
Il n’existe pas de solution idéale universelle, tout dépend de vos besoins et de la complexité de votre application.

Veillez à toujours effectuer vos appels à la base sur un thread en arrière plan

Ce n’est certainement ni la première, ni la dernière fois que vous le lisez : Il est important de ne pas bloquer votre thread UI avec des traitements lourds.

Ceci a pour conséquence de bloquer l’affichage de votre application, comportement qui mène à de nombreux points négatifs :

  • Utilisateurs frustrés ne pas savoir ce qu’il se passe
  • Impression générale de manque de finitions
  • Clicks compulsifs jusqu’à ce que « quelque chose se passe » qui empirent la situation!

De plus pour les traitements massifs sur la base, il semblerait que l’utilisation d’un thread en arrière plan accélère assez significativement les choses, voir ce lien.

Améliorer les temps d’exécution en lecture

Stockez sous forme de blobs lorsque que la situation s’y prête

Dans certains cas, il est plus rentable de stocker un bloc entier de données sérialisées (en XML ou binaire) directement en base sous la forme d’un blob dans une colonne de type text, varbinary, binary par exemple.

Cela permet de limiter autant le nombre de requêtes et d’allers et retours avec le base que la complexité et la quantité de données à requêter sont grandes.

Créez des index sur les propriétés utilisées fréquemment

Un index est automatiquement crée pour chaque colonne de la base définie en tant que clé primaire. Mais vous pouvez également créer vos propres index sur les propriétés souvent utilisées dans vos requêtes LINQ, y compris celles utilisées pour trier les résultats des requêtes.

[Index(Column=”OrderID ASC, Quantity DESC”)]

Compilez vos requêtes LINQ

Lors de chaque exécution de requêtes LINQ, LINQ to SQL traduit l’arbre d’expression défini vers le code Transact-SQL correspondant. Ce mode de fonctionnement s’avère peu optimal pour les requêtes LINQ qui sont exécutées de nombreuses fois au cours de la durée de vie de l’application.

Pour éviter que cette opération de traduction ne soit exécutée encore et encore, il est possible de compiler votre requête LINQ à l’aide de CompiledQuery.Compile.

Cette méthode produit une requête Transact-SQL paramétrée qu’il vous sera possible de réutiliser avec des paramètres d’entrés différents par l’intermédiaire de la Func retournée.

Effectuez les jointures par vos propres moyens?

Cela peut sembler étrange, mais lorsque l’on travaille avec de grandes volumétries, récupérer les données dont vous avez besoin avec des requêtes très simples puis effectuer les jointures par ses propres moyens se révèle bien souvent plus efficace que de laisser faire SQL CE. A condition bien sûr, que la quantité de données ne soit pas excessive! (quota de 90 mo par application sur Windows Phone 7)

Le post suivant y fait d’ailleurs référence dans sa conclusion.

Améliorer les temps d’exécution en écriture

Ajoutez la colonne RowVersion pour améliorer les updates et deletes

Avant d’effectuer des updates ou des deletes, LINQ to SQL doit s’assurer qu’il n’y pas de conflits dus à des accès concurrentiels.

Afin de vérifier que les entités reflètent bien les valeurs présentes en base en moment du SubmitChanges, ces opérations sont effectuées avec une clause where supplémentaire qui vérifie les valeurs de chacune des colonnes. Cette dernière alourdit donc autant les requêtes que la table concernée contient de colonnes.

Pour éviter ces traitements supplémentaires, il est possible de définir une colonne de type RowVersion.

private Binary _version;

Lorsqu’elle est présente, LINQ to SQL se base uniquement sur la valeur contenue dans ce champ pour déterminer si une entrée a changé ou non et la clause where supplémentaire, devenue inutile, disparaît.

Pour plus d’informations sur le sujet, rendez-vous ici et ici.

Quelques pistes pour améliorer les performances des inserts

Pour optimiser un scénario dans lequel une grande quantité de données doit être insérée en base vous pouvez utiliser le paramètre « Max Buffer Size ». Par défaut, sa valeur est de 384 ko et 5120 ko au maximum. Ce paramètre indique à la base la plus grande quantité de données qu’elle peut stocker en mémoire avant de l’écrire sur le disque, 1024 KB semble être un bon compromis. Attention toutefois à ce pas trop l’augmenter, au delà d’une certaine valeur, cela n’aura plus d’impacts positifs mais négatifs! Pour plus d’informations voir cet article.

La présence de la colonne RowVersion fait gagner du temps sur les opérations d’updates et de deletes. A l’inverse, dans le cas d’un insert, RowVersion constitue une donnée de plus à insérer en base et à générer par LINQ to SQL. Si vous souhaitez privilégier les inserts sur les updates/deletes et les accélérer sensiblement, supprimez cette colonne. A noter que cette optimisation ne concerne à nouveau que les cas d’insertions massifs de données. Pour plus d’informations voir ce post traduit.

Privilégiez l’utilisation de InsertAllOnSubmit à InsertOnSubmit pour de nombreux inserts consécutifs

Enfin, si vous cherchez à injecter rapidement une grande quantité de données dans votre base, sachez qu’il existe un portage de SqlBulkCopy pour Windows Phone 7.5, vous le trouverez à cette adresse.

Minimiser la consommation mémoire

Désactivez le suivi de modifications lorsqu’il n’est pas utile

Par défaut, vos instances de DataContext sont configurées de manière à ce qu’une copie de toutes les entités issues de la base soit effectuée et conservée. Ces copies originales sont utilisées par la suite lors de l’appel à la méthode SubmitChanges pour déterminer ce qui a changé et générer les requêtes Transact-SQL adéquates (insert, update, delete etc…).

Ce mécanisme peut être désactivé pour les scénarios dans lesquels les données sont consultables et non modifiables et ainsi économiser la mémoire utilisée par ces copies. Pour ce faire, assignez false à la propriété ObjectTrackingEnabled de votre DataContext courant.

Implémentez l’interface INotifyPropertyChanging

L’interface INotifyPropertyChanging permet de modifier quelque peu la manière dont LINQ to SQL assure le suivi des modifications afin de réduire l’empreinte mémoire de votre application.

Sans implémentation de cette interface sur vos objet POCOs liés à LINQ to SQL, ce dernier est contraint de dupliquer toutes les entités lues à partir de la base de données afin d’en conserver une copie originale. Lors de l’appel à la méthode SubmitChanges, il détermine si une entité a changé et qu’est-ce qui a changé en comparant ses valeurs actuelles avec celles de sa copie originale.

En revanche, si l’interface INotifyPropertyChanging est implémentée, LINQ to SQL est directement informé de la modification des entités et seules ces dernières sont dupliquées. Ce qui réduit grandement le nombre de copies effectuées.


Après s’être longtemps fait désirée, Mango apporte enfin une solution de stockage de données native sur Windows Phone avec une version SQL CE spécialement dédiée à Windows Phone.

Malgré ses défauts et certaines alternatives viables, SQL CE for Windows Phone constitue une solution particulièrement adaptée pour les applications amenées à travailler sur de grandes quantités de données à la fois en lecture et en écriture sur Windows Phone 7. D’autant qu’iI existe bon nombres de solutions et d’astuces pour améliorer les temps d’exécutions ainsi que l’empreinte mémoire de l’indissociable couple SQL CE/LINQ to SQL.

L’arrivée de Windows Phone 8 souffle un vent nouveau dans le domaine du stockage de données sur les appareils mobiles Microsoft. Avec la possibilité de développer directement en natif, d’autres solutions de stockage, jouant désormais à armes égales avec SQL CE, pourraient bien faire leur apparition et représenter de très sérieuses alternatives. SQLlite for Windows Phone 8 en est déjà un exemple concret. Si vous souhaitez en savoir plus sur le sujet, je vous invite à consulter cet article ou encore celui-ci.