Jérôme Lambert » ADO.NET

Modèle Entity Framework généré avec SQL Server 2008 et utilisé sous SQL Server 2005

Jérôme Lambert — Fri, 15 Apr 2011 19:37:29 +0000

Suite à un déploiement d’une application chez un client, j’ai eu la mauvaise surprise de constater que cette application ne fonctionnait pas dans l’environnement de production. Après un petit temps à déboguer l’application, je découvre l’erreur suivante :

The version of SQL Server in use does not support datatype ‘datetime2′.

Au niveau du code, je ne fais jamais mention de ce type « datetime2″. Cu côté de la base de données, tous mes champs utilisent le type « datetime ». Même pas les nouveaux types « date » et « time » de SQL Server 2008. Très vite, je commence à me dire que la base de données est très certainement en cause car dans mon environnement de développement, la base de données est sous SQL Server 2008, alors que dans l’environnement de mon client, la base de données est sous SQL Server 2005.

Finalement, je finis par trouver la réponse lors de recherches sur le web et le problème a bien un lien avec la base de données mais pas directement car le responsable est le modèle Entity Framework ! Lors de la création de ce modèle, le designer a pris en compte le type de serveur qui a servit à générer mon modèle et dans mon cas, c’était SQL Server 2008. Cette information est utile pour Entity Framework car cela va lui permettre d’optimiser les requêtes générées vers la base de données lors de l’exécution de l’exécution car l’utilisation du type « datetime2″ est plus performante dans le cas où le serveur SQL est en version 2008. Malheureusement ce type n’est pas reconnu sous SQL Server 2005 et Entity Framework ne changera pas de stratégie dans ce cas là.

La solution est donc dans le modèle Entity Framework.

Ouvrez votre modèle avec « Open With » et sélectionnez « XML (Text) Editor ».

 Namespace="SampleModel.Store" 
Alias="Self" 
Provider="System.Data.SqlClient" 
ProviderManifestToken="2008" 
xmlns:store=http://schemas.microsoft.com/ado/2007/12/edm/EntityStoreSchemaGenerator 
xmlns=http://schemas.microsoft.com/ado/2009/02/edm/ssdl />

Vous trouverez au début de votre fichier un attribut « ProviderManifestToken » comme ci-dessus avec la valeur « 2008 ». Il vous suffit de remplacer la valeur par « 2005 » et Entity Framework génèrera à l’avenir du code à l’exécution compatible avec les bases de données SQL Server 2005.

Par contre, une mauvaise nouvelle. A chaque fois que vous mettrez à jour votre modèle, la valeur sera mise à jour en fonction de la base de données que vous utilisez.

Dommage !

Téléchargez les premiers providers ADO.NET SQLite, Oracle, MySQL et PostgreSQL avec support de ADO.NET Entity Framework

Jérôme Lambert — Sun, 07 Sep 2008 23:04:58 +0000

Depuis les versions béta de ADO.NET Entity Framework, nous étions contraints de nous contenter de SQL Server pour la compatibilité avec ce framework. Certes, des sociétés ont développé des providers pour une compatibilité avec d’autres systèmes de gestion de base de données mais beaucoup attendaient la version finale de ADO.NET Entity Framework. Aujourd’hui, on commence tout doucement à voir apparaître différents providers offrant une compatibilité avec d’autres SGBD, c’est le cas de SQLLite, Oracle, MySQL et PostgreSQL.

Premier provider disponible en même temps que la sortie de la version RTM de ADO.NET Entity Framework (ce n’est pas rien !) : System.Data.SQLite, développé par Robert Simpson de la société Phoenix Software International. Ce provider est open source et téléchargeable sur SourceForge.net.

Et dernièrement, c’est la société Devart qui a annoncé la mise à jour de ses providers ADO.NET :

OraDirect .NET
MyDirect .NET
PostgreSQL .NET

Ces mises à jour incluent bien évidemment un support de ADO.NET Entity Framework. Les produits Devart étant payant, vous pourrez tout de même télécharger des versions d’évaluation de 30 jours sur le site de la société.

Un petit résumé des liens indispensables :

Voila une belle voix ouverte et quelque chose me dit que ces providers sont loin d’être les derniers… Patience donc.

Résultat de procédure stockée incorrect avec Linq to SQL

Jérôme Lambert — Fri, 29 Aug 2008 01:08:19 +0000

Aujourd’hui mon patron m’interpelle concernant un comportement étrange d’une procédure stockée avec Linq to SQL. La procédure stockée est un simple « SELECT field1, COUNT(*) » et pourtant impossible de récupérer un résultat correct.

Histoire de pouvoir vous montrer des exemples concrets, je vais transposer la situation avec l’utilisation de la base de données Northwind.

Comme je vous le disais, la procédure stockée récalcitrante consiste à récupérer la liste des clients avec le nombre de commandes qu’ils ont passé :

CREATE PROCEDURE GetCustomersWithOrderCount
AS
BEGIN
    SELECT Customers.ContactName, COUNT(*)
    FROM Customers INNER JOIN Orders
    ON Customers.CustomerID = Orders.CustomerID
    GROUP BY Customers.ContactName
END

Au niveau du projet, un modèle Linq to SQL Classes auquel on a ajouté la procédure stockée « GetCustomersWithOrderCount ».

Comme on peut le voir dans le code généré, Linq to SQL a déduit la classe correspondant au résultat que la procédure stockée va renvoyer. En l’absence d’alias sur le champ « COUNT(*) », le nom « Column1″ a été donné par défaut.

public partial class GetCustomersWithOrderCountResult
{
    private string _ContactName;
    private System.Nullable _Column1;
    public GetCustomersWithOrderCountResult()
    {
    }
    [Column(Storage= »_ContactName », DbType= »NVarChar(30) »)]
    public string ContactName
    {
        get
        {
            return this._ContactName;
        }
        set
        {
            if ((this._ContactName != value))
            {
                this._ContactName = value;
            }
        }
    }
    [Column(Storage= »_Column1″, DbType= »Int »)]
    public System.Nullable Column1
    {
        get
        {
            return this._Column1;
        }
        set
        {
            if ((this._Column1 != value))
            {
                this._Column1 = value;
            }
        }
    }
}

Tout semble correct et on peut donc écrire le code qui va récupérer le résultat de la procédure stockée que nous avons précédemment créé :

using (ModelDataContext ctx = new ModelDataContext())
{
    foreach (var item in ctx.GetCustomersWithOrderCount().ToList())
    {
        Console.WriteLine(« {0} – {1} », item.ContactName, item.Column1);
    }
}

Pourtant, lorsqu’on lance le programme, on obtient un résultat plus qu’étrange :

On récupère bien nos clients mais par contre aucune valeur pour le nombre de commandes et ce pour tous les clients ! Après une heure de recherche, je trouve enfin la solution via MSDN (une fois de plus ;)).

Ce qui se passe, c’est que Linq to SQL ne sait pas comment mapper le champ « COUNT(*) » de la procédure stockée à la propriété « Column1″ de la classe « GetCustomersWithOrderCountResult » générée automatiquement.

La solution est donc simple : il suffit de donner un alias à notre champ dans la procédure stockée :

ALTER PROCEDURE GetCustomersWithOrderCount
AS
BEGIN
    SELECT Customers.ContactName, COUNT(*) as OrderCount
    FROM Customers INNER JOIN Orders
    ON Customers.CustomerID = Orders.CustomerID
    GROUP BY Customers.ContactName
END

Après une mise à jour du schéma Linq to SQL Classes, on peut remarquer que le changement a été pris en compte dans la classe « GetCustomersWithOrderCountResult ». La propriété « Column1″ a bien été renommée en « OrderCount ».

public partial class GetCustomersWithOrderCountResult
{
    private string _ContactName;
    private System.Nullable _OrderCount;
    public GetCustomersWithOrderCountResult()
    {
    }
    [Column(Storage= »_ContactName », DbType= »NVarChar(30) »)]
    public string ContactName
    {
        get
        {
            return this._ContactName;
        }
        set
        {
            if ((this._ContactName != value))
            {
                this._ContactName = value;
            }
        }
    }
    [Column(Storage= »_OrderCount », DbType= »Int »)]
    public System.Nullable OrderCount
    {
        get
        {
            return this._OrderCount;
        }
        set
        {
            if ((this._OrderCount != value))
            {
                this._OrderCount = value;
            }
        }
    }
}

Et lorsqu’on exécute à nouveau notre code, on a enfin notre résultat tant attendu :

Tout ça pour ça vous allez me dire mais c’est bon de le savoir quand même car au final, je peux vous assurer que l’on a perdu beaucoup de temps avant de comprendre ce qui n’allait pas

N’hésitez pas à réagir en laissant un commentaire.

Quoi de neuf pour ADO.NET Entity Framework avec VS 2008 SP1 ?

Jérôme Lambert — Tue, 12 Aug 2008 20:29:54 +0000

Comme annoncé hier, la sortie du Service Pack 1 pour Visual Studio 2008 et .NET Framework 3.5 a conduit à des projets enfin disponibles dans leur version finale. C’est le cas pour ADO.NET Entity Framework et la team ADO.NET a réagit assez vite pour nous donner la liste des changement qui ont eu lieu dans cette version finale.

Je vous laisse donc découvrir ces changements directement sur le billet de la team ADO.NET.

A savoir que les samples ont aussi été mis à jour, rendez-vous ici pour en savoir plus.

[Edit] La team .NET vient de poster sur le blog la liste des « breaking changes » de cette nouvelle release. Ces changements concernent le provider, entity services, mapping & metadata, EntityDataSource ainsi que les tools.

Service Pack 1 pour Visual Studio 2008 et le .NET Framework 3.5 disponible

Jérôme Lambert — Tue, 12 Aug 2008 01:18:37 +0000

Des rumeurs laissaient sous entendre un Service Pack 1 pour bientôt, c’est maintenant officiel, vous pouvez dès aujourd’hui télécharger le Service Pack 1 (SP1) pour Visual Studio 2008 et le .NET Framework 3.5. Pour les utilisateurs de versions Express, le SP1 est aussi disponibles pour ces versions.

Si il y a deux mots que Microsoft veut faire passer pour cette mise à jour, ce sont fiabilité et performance. WPF, AJAX, ADO.NET, JavaScript ou encore déploiement, tout y passe et vous ne serez certainement pas déçu :

Améliorations des performances des designers pour les applications WPF
Améliorations des outils pour le développement d’applications AJAX
Améliorations des designers pour le travail avec ADO.NET Entity Framework
Meilleur support de JavaScript
Déploiement d’applications web simplifié

Mais ce service pack, c’est aussi des nouveautés ainsi que des projets passés en versions finales :

.NET Framework Client Profile
ADO.NET Entity Framework
ADO.NET Data Services
Support de SQL Server 2008
ASP.NET Dynamic Data

Pour les téléchargements, je vous redirige sur le blog de Benjamin qui a déjà fait le nécessaire pour récolter tout ce qu’il faut savoir

Moi qui attendais la version finale de ADO.NET Entity Framework pour écrire un article sur le sujet, je suis plus que satisfait ^^

Bon développement à tous !

ADO.NET Entity Framework V2.0 – Un nouveau blog pour plus de transparence

Jérôme Lambert — Wed, 25 Jun 2008 01:15:36 +0000

We would like to start by being as transparent as possible in our design process

Voila les mots que l’on a pu lire sur le blog de l’équipe ADO.NET de Microsoft en charge du projet Entity Framework.

Comme annoncé, aujourd’hui marque le premier jour où le processus de conception commence pour la prochaine version : Entity Framework V2.0.

L’équipe ADO.NET ayant une réelle envie de fournir un framework répondant au mieux aux besoins métiers des développeurs, une transparence sera de mise afin de recueillir le feedback des développeurs de communautés durant le processus de conception de cette nouvelle version de l’Entity Framework.

Afin d’y arriver, un nouveau blog, appelé Entity Framework Design, a été mis en place dans le but que l’équipe ADO.NET puisse fournir l’avancée sur le design du framework. En retour, vous êtes invités à donner votre avis au travers du blog afin que l’équipe ADO.NET puisse valider ou réajuster chaque étape du design.

Entity Framework et ADO.NET Data Services prévus pour VS 2008 et .NET 3.5 SP1

Jérôme Lambert — Wed, 09 Apr 2008 23:30:13 +0000

Annoncé sur le blog de la team ADO.NET, Entity Framework (et son Entity Designer) ainsi que ADO.NET Data Services passeront en version RTM dans le futur SP1 de Visual Studio 2008 et .NET 3.5.

Ne vous réjouissez pas trop vite, il n’est pas indiqué de sortie prochaine pour ce Service Pack. L’équipe ADO.NET recommande juste de surveiller la sortie du SP1 en version beta 1 car ce sera la dernière occasion pour remonter les éventuels bugs qui resteraient.

Patience donc

[TechDays 2008] ADO.NET Entity Framework

Jérôme Lambert — Tue, 12 Feb 2008 01:17:06 +0000

- Matthieu Mezil – Société Winwise
– Michel Perfetti – MVP C# – Société Winwise

C’est avec cette première session que l’aventure TechDays 2008 a débuté.

Autant je m’attendais à un sujet très intéressant, autant je pensais ne pas en apprendre autant et le tout plutôt bien expliqué. Il me semble d’ailleurs que pour Matthieu c’était la première vraie session en tant que speaker et je dois avouer que j’ai été agréablement surpris, le sujet avait été très bien préparé par le deux intervenants.

Que dire de ADO.NET Entity Framework ? Tout d’abord pour ceux qui n’y connaissent rien du tout sur le sujet, c’est un framework qui va permettre à tout développeur de travailler sur un modèle conceptuel et non plus sur le modèle relationnelle d’une base de données. En gros résumé, on va manipuler des Data Objects sans se soucier du modèle relationnel. Ce fameux modèle conceptuel est appelé le Entity Data Model (EDM) et c’est ce modèle que nous allons requêter (le plus souvent avec Entity SQL et Linq To Entities) pour interagir de manière abstraite avec la base de données.

C’est donc grâce à un système de mapping que cette relation entre le modèle conceptuel et la modèle relationnel va pouvoir être effectuée, mais tout ça de manière « transparente » pour le développeur mais je vous passe les détails car vous pourrez en apprendre plus via les liens fournis en fin de ce billet.

Pour en revenir à l’EDM, outre le fait qu’une table en base de données devient un Data Object dans notre EDM (excepté les tables de relation), il va être possible d’aller assez loin avec ce modèle. Dans les grandes lignes, vous aurez la possibilité de :

Fusionner vos tables
Utiliser l’héritage de différentes façon (voir Table per Type & Table per Hierarchy)
Extraire des parties communes de vos tables pour en faire des types complexes (voir Complex Types)
Représenter vos objets grâce à des vues
Personnaliser les requêtes SQL générées en utilisant soit vos procédures stockées, soit du SQL

En vrac, vous pouvez aussi accéder à un cache de tracking qui permet de connaître l’état de chaque ligne, tracer les changements, résoudre les conflits. Vous pouvez aussi « compiler » vos requêtes (voir Compiled Query) via les délégués. Sans oublier la synchronisation qui est omniprésente.

Voila, je me doute que ce résumé n’est pas très digeste mais vous commencez au moins avec les mots clés sur le sujet. Les liens ci-dessous vous permettront d’apprendre tout ce qu’il faut savoir sur ADO.NET Entity Framework.

A noter que le projet est toujours en beta 3 et sera normalement disponible dans sa version finale vers Juin 2008.

Blog Team ADO.NET Documentation MSDN ADO.NET Entity Framework
Télécharger ADO.NET Entity Framework Beta 3
Télécharger ADO.NET Entity Framework Tools December 2007 CTP
Liste des providers qui seront disponibles lors de la version finale

[TechDays 2008] ADO.NET Data Services – Astoria

Jérôme Lambert — Wed, 13 Feb 2008 21:39:05 +0000

- Mitsu Furuta – Microsoft France
– Pierre Lagarde – Microsoft France

Troisième session… Troisième « nouveauté » et évidemment, c’est toujours en beta pour ne pas changer

Microsoft Astoria… Ou plutôt ADO.NET Data Services (qui semble être le nom définitif) est un framework, respectant la technologie REST, qui permet d’exposer des sources de données sur le web sous forme de services dans le but de les requêter. Et pour une session comme celle la, des speakers de marque qui sont Mitsu et Pierre Lagarde, un duo vraiment plaisant à suivre.

Avec l’introduction précédente, vous avez du tilter deux fois. Premièrement, j’ai parlé de « services » ce qui signifie que WCF va être présent. Deuxièmement, j’ai dit qu’il allait être possible de « requêter » ces services et là on pense tout de suite à Linq ou plus précisément Linq To HTTP car c’est réellement des URL qui vont être construites via Linq dans le but de récupérer des données. Pour ceux qui iront plus loin dans cette nouvelle technologie, vous apprendrez que les données renvoyées pourront être soit sous le format JSON (JavaScript Object Notation), soit sous le format Atom/App.

On va donc pouvoir accéder à ces services par simple requête HTTP en passant des ordres tels que GET, POST, PUT et DELETE fournissant toutes les opération nécessaires pour lire, écrire, modifier et supprimer sur les données exposées au travers des services.

Du côté des sources de données, ADO.NET Data Services se base sur l’ADO.NET Entity Framework via l’Entity Data Model qui offre une couche d’asbtraction des données.

Preuve à l’appui, je vais vous donner un exemple extrêmement basique et sûrement pas nécessairement correcte mais le principe sera là. Imaginez qu’un service donné expose une méthode qui permet de récupérer des clients via son interface. On pourra donc entrer l’URL suivante dans un navigateur web:

http://localhost/servicey.svc/Customers

Et rien qu’en appelant cette URL, on va récupérer notre liste de clients avec leurs informations liées le tout sous format XML. Allons plus loin, on va pouvoir récupérer un client donné via son index :

http://localhost/servicey.svc/Customers(0)

Et pourquoi pas ne demander que le nom du client à l’index 0 ?!…

http://localost/servicey.svc/Customers()/Name

Je vais arrêter les exemples là mais le système va encore plus loin en permettant de spécifier des conditions tel que : « Je ne veux que les clients dont le nom commence par ‘A' ».

Dans l’exemple que je viens de vous donner, j’ai requêter mon service via des URL mais ne vous inquiétez pas car grâce à Linq To HTTP vous allez passer par un proxy pour que ce formatage d’URL soit totalement transparent pour vous. L’URL « http://localhost/servicey.svc/Customers » donnera en Linq :

var q = from c in servicey.Customers
select c;

Le résultat sera exactement le même.

J’espère que cet avant goût vous a donner l’envie d’en apprendre bien plus car ça en vaut le coup, croyez moi.

A noter que ce framework est disponible directement avec les ASP.NET Futures.

Les liens à ne pas rater :

Présentation d’ADO.NET Data Services par notre Thomas
Téléchargez ASP.NET Futures July 2007
Téléchargez ADO.NET Entity Framework beta 3

[Astuce] Résoudre les exceptions de contraintes sur les DataSet

Jérôme Lambert — Fri, 08 Feb 2008 01:17:30 +0000

Si vous utilisez régulièrement les DataSet, vous reconnaîtrez sûrement le message suivant :

Impossible d’activer les contraintes. Une ou plusieurs lignes contiennent des valeurs qui violent les contraintes de type non null, unique ou de clé externe.

Ce message est lancé lorsqu’on remplit un DataSet avec des données qui ne respectent pas les contraintes définies sur le DataSet. Exemples :

Violation d’unicité,
Le type n’est pas le même,
La taille du champ n’est pas respecté,
…

Et pourtant quand on reçoit cette exception de type System.Data.ConstraintException, on a pas d’autre information dans cet objet pour déterminer la source du problème. Et c’est vrai que je n’ai jamais eu besoin de plus d’information tellement mes erreurs me sautaient aux yeux en regardant les données que j’essayais de charger dans mes DataSet. Cette façon de faire fonctionne très bien sur des petites tables mais quand on a des tables avec au minimum 20 champs, c’est plus délicat… Comment faire dans ce cas là ?

Les DataTable, composant votre DataSet, possèdent une méthode appelée GetErrors() qui permet tout simplement de récupérer un tableau de type DataRow. Cette liste représente chaque erreur de contrainte au sein du DataTable.

Comme exemple, j’ai créé une petite table « Clients » en base de données avec un champ « Nom » de type texte fixé à 20 caractères maximum.

Dans mon projet sous Visual Studio, j’ai créé un DataSet typé où j’y ai glissé cette fameuse table « Clients » afin d’en faire un DataTable et pour la beauté de la démo, j’ai fixé la longueur du champ « Nom » à 10 caractères au lieu de 20.

Ci-dessous, le code qui va charger les données de la base dans le DataSet :

Ce qui provoquera l’exception attendue avec comme résultat à l’écran :

La colonne ‘nom’ dépasse la limite MaxLength.
La colonne ‘nom’ dépasse la limite MaxLength.
La colonne ‘nom’ dépasse la limite MaxLength.
La colonne ‘nom’ dépasse la limite MaxLength.
La colonne ‘nom’ dépasse la limite MaxLength.

Bon développement en espérant vous avoir fait économisé quelques secondes de recherches