Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cette section décrit les problèmes connus liés au fournisseur de données .NET Framework pour SQL Server (SqlClient).
Espaces de fin dans les fonctions de chaîne
SQL Server ignore les espaces de fin dans les valeurs de chaîne. Par conséquent, le passage d'espaces de fin dans la chaîne peut provoquer des résultats imprévisibles, voire des défaillances.
Si vous devez absolument conserver des espaces à la fin de votre chaîne, envisagez d’ajouter un espace à la fin pour que SQL Server ne coupe pas la chaîne. Si les espaces de fin ne sont pas indispensables, ils doivent être supprimés avant le passage au pipeline de la requête.
Fonction RIGHT
Si une valeur non-null est passée comme premier argument et que 0 est passé comme deuxième argument à RIGHT(nvarchar(max), 0) ou RIGHT(varchar(max), 0), un NULL est retourné au lieu d'une chaîne empty.
Opérateurs CROSS et OUTER APPLY
Les opérateurs CROSS et OUTER APPLY ont été introduits dans SQL Server 2005. Dans certains cas, le pipeline de requête peut produire une instruction Transact-SQL qui contient des opérateurs CROSS APPLY et/ou OUTER APPLY. Étant donné que certains fournisseurs principaux, y compris les versions de SQL Server antérieures à SQL Server 2005, ne prennent pas en charge ces opérateurs, ces requêtes ne peuvent pas être exécutées sur ces fournisseurs principaux.
Voici quelques scénarios typiques qui peuvent entraîner la présence d’opérateurs CROSS APPLY et/ou OUTER APPLY dans la requête de sortie :
sous-requête corrélée avec pagination ;
AnyElementsur une sous-requête corrélée ou sur une collection produite par navigation ;Requêtes LINQ qui utilisent des méthodes de regroupement qui acceptent un sélecteur d’élément.
requête dans laquelle un CROSS APPLY ou un OUTER APPLY est explicitement spécifié ;
requête dotée d'une construction DEREF sur une construction REF.
Opérateur SKIP
Si vous utilisez SQL Server 2000, l’utilisation de SKIP avec ORDER BY sur des colonnes non clés peut retourner des résultats incorrects. Le nombre de lignes ignorées peut être supérieur au nombre de lignes spécifié si la colonne non-clé contient des données en double. Cela est dû à la façon dont SKIP est traduit pour SQL Server 2000. Par exemple, dans la requête suivante, plus de cinq lignes peuvent être ignorées si E.NonKeyColumn elles ont des valeurs en double :
SELECT [E] FROM Container.EntitySet AS [E] ORDER BY [E].[NonKeyColumn] DESC SKIP 5L
Ciblage de la version correcte de SQL Server
Entity Framework cible la requête Transact-SQL basée sur la version SQL Server spécifiée dans l’attribut ProviderManifestToken de l’élément Schema dans le fichier de modèle de stockage (.ssdl). Cette version peut différer de la version du serveur SQL Server réel auquel vous êtes connecté. Par exemple, si vous utilisez SQL Server 2005, mais que votre ProviderManifestToken attribut est défini sur 2008, la requête de Transact-SQL générée peut ne pas s’exécuter sur le serveur. Par exemple, une requête qui utilise les nouveaux types d’heure de date qui ont été introduits dans SQL Server 2008 ne s’exécute pas sur les versions antérieures de SQL Server. Si vous utilisez SQL Server 2005, mais que votre ProviderManifestToken attribut est défini sur 2000, la requête générée Transact-SQL peut être moins optimisée, ou vous pouvez obtenir une exception indiquant que la requête n’est pas prise en charge. Pour plus d’informations, consultez la section Opérateurs CROSS et OUTER APPLY, plus haut dans cette rubrique.
Certains comportements de base de données dépendent du niveau de compatibilité défini sur la base de données. Si votre ProviderManifestToken attribut est défini sur 2005 et que votre version de SQL Server est 2005, mais que le niveau de compatibilité d’une base de données est défini sur « 80 » (SQL Server 2000), le Transact-SQL généré cible SQL Server 2005, mais peut ne pas s’exécuter comme prévu en raison du paramètre de niveau de compatibilité. Par exemple, vous risquez de perdre les informations de classement si un nom de colonne dans la liste ORDER BY correspond à un nom de colonne dans le sélecteur.
Requêtes imbriquées dans la projection
Les requêtes imbriquées dans une clause de projection peuvent être traduites en requêtes de produit cartesiennes sur le serveur. Sur certains serveurs back-end, y compris SQL Server, cela peut faire en sorte que la table TempDB devienne assez volumineuse. Cela peut réduire les performances du serveur.
Voici un exemple de requête imbriquée dans une clause de projection :
SELECT c, (SELECT c, (SELECT c FROM AdventureWorksModel.Vendor AS c ) As Inner2 FROM AdventureWorksModel.JobCandidate AS c ) As Inner1 FROM AdventureWorksModel.EmployeeDepartmentHistory AS c
Valeurs d’identité GUID générées par le serveur
Entity Framework prend en charge les valeurs d’identité de type GUID générées par le serveur, mais le fournisseur doit prendre en charge le retour de la valeur d’identité générée par le serveur après l’insertion d’une ligne. À compter de SQL Server 2005, vous pouvez retourner le type GUID généré par le serveur dans une base de données SQL Server via la clause OUTPUT.