Changements essentiels dans les fonctionnalités du moteur de base de données de SQL Server 2014

Cette rubrique décrit les changements cassants dans le moteur de base de données SQL Server 2014 et les versions antérieures de SQL Server. Ces modifications peuvent interrompre les applications, scripts ou fonctionnalités fondés sur les versions antérieures de SQL Server. Il se peut que vous rencontriez ces problèmes lors d'une mise à niveau. Pour plus d'informations, consultez Use Upgrade Advisor to Prepare for Upgrades.

Modifications avec rupture dans SQL Server 2014

Aucun nouveau problème.

Changements essentiels apportés à SQL Server 2012

Transact-SQL

Vues de gestion dynamique

Affichages catalogue

Types de données SQL CLR (geometry, geography et hierarchyid)

L’assemblyMicrosoft.SqlServer.Types.dll, qui contient les types de données spatiales et le type hierarchyid, a été mis à niveau de la version 10.0 vers la version 11.0. Les applications personnalisées qui font référence à cet assembly peuvent échouer lorsque les conditions suivantes sont remplies.

• Lorsque vous déplacez une application personnalisée d’un ordinateur sur lequel SQL Server 2008 R2 a été installé vers un ordinateur sur lequel seul SQL Server 2014 est installé, l’application échoue, car la version 10.0 référencée de l’assembly SqlTypes n’est pas présente. Ce message d'erreur peut s'afficher : "Could not load file or assembly 'Microsoft.SqlServer.Types, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified."

• Lorsque vous référencez l’assembly SqlTypes version 11.0 et que la version 10.0 est également installée, ce message d’erreur peut s’afficher : "System.InvalidCastException: Unable to cast object of type 'Microsoft.SqlServer.Types.SqlGeometry' to type 'Microsoft.SqlServer.Types.SqlGeometry'."

• Lorsque vous référencez l’assembly SqlTypes version 11.0 à partir d’une application personnalisée qui cible .NET 3.5, 4 ou 4.5, l’application échoue, car SqlClient charge la version 10.0 de l’assembly. Cette erreur se produit lorsque l'application appelle l'une des méthodes suivantes :

  • méthode GetValue de la classe SqlDataReader

  • méthode GetValues de la classe SqlDataReader

  • opérateur d'index de crochets [] de la classe SqlDataReader

  • méthode ExecuteScalar de la classe SqlCommand

Vous pouvez contourner ce problème en utilisant l’une des méthodes suivantes :

• Vous pouvez contourner ce problème dans votre code en appelant la GetSqlBytes méthode, au lieu des méthodes Get répertoriées ci-dessus, pour récupérer les types de système CLR SQL Server, comme illustré dans l’exemple suivant :

  string query = "SELECT [SpatialColumn] FROM [SpatialTable]";  
        using (SqlConnection conn = new SqlConnection("..."))  
        {  
              SqlCommand cmd = new SqlCommand(query, conn);  
  
              conn.Open();  
              SqlDataReader reader = cmd.ExecuteReader();  
  
              while (reader.Read())  
              {  
                    // In version 11.0 only  
                    SqlGeometry g =   
  SqlGeometry.Deserialize(reader.GetSqlBytes(0));  
  
                    // In version 10.0 or 11.0  
                    SqlGeometry g2 = new SqlGeometry();  
                    g.Read(new BinaryReader(reader.GetSqlBytes(0).Stream));  
              }  
        }  
  

• Vous pouvez contourner ce problème en utilisant la redirection d'assembly dans le fichier de configuration de l'application, comme le montre l'exemple suivant :

  <runtime>  
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">  
      ...  
      <dependentAssembly>  
          <assemblyIdentity name="Microsoft.SqlServer.Types" publicKeyToken="89845dcd8080cc91" culture="neutral" />  
          <bindingRedirect oldVersion="10.0.0.0" newVersion="11.0.0.0" />  
      </dependentAssembly>  
      ...  
  </assemblyBinding>  
  <runtime>  
  

• Vous pouvez contourner ce problème dans votre chaîne de connexion en spécifiant la valeur « SQL Server 2012 » pour que de l'attribut « Type System Version » force SqlClient à charger la version 11.0 de l'assembly. Cet attribut de chaîne de connexion est uniquement disponible dans le .NET 4.5 et versions ultérieures.

• La balise assemblyBinding doit être encapsulée sous la balise runtime.

Prise en charge d'AWE

La prise en charge d'AWE (Address Windowing Extensions) 32 bits a été arrêtée. Cela peut entraîner une baisse des performances sur les systèmes d'exploitation 32 bits. Pour les installations utilisant de grandes quantités de mémoire, migrez vers un système d'exploitation 64 bits.

Les fonctions XQuery prennent en charge la substitution

La recommandation du W3C pour les fonctions et les opérateurs XQuery exigent qu'ils prennent en charge une paire de substitution qui représente un caractère Unicode à plage élevée en tant que glyphe unique dans l'encodage UTF-16. Toutefois, dans les versions de SQL Server antérieures à SQL Server 2012, les fonctions de chaîne ne reconnaissaient pas les paires de substitution en tant que caractère unique. Certaines opérations de chaîne, telles que les calculs de longueur de chaîne et les extractions de sous-chaînes, ont retourné des résultats incorrects. SQL Server 2012 prend désormais entièrement en charge UTF-16 et la gestion correcte des paires de substitution.

Le type de données XML dans SQL Server autorise uniquement les paires de substitution bien formées. Toutefois, certaines fonctions peuvent toujours retourner des résultats indéfinis ou inattendus dans certaines circonstances, étant donné qu'il est possible de passer des paires de substitution non valides ou partielles aux fonctions XQuery comme valeurs de chaîne. Considérez les méthodes suivantes pour générer des valeurs de chaîne lors de l’utilisation de XQuery dans SQL Server :

• Fournissez une valeur de chaîne constante comme valeur binaire. Lorsque vous utilisez cette méthode, il est possible de passer des paires de substitution non valides ou partielles.

• Fournissez une valeur de chaîne constante en fournissant des entités de caractère. Lorsque vous utilisez cette méthode, il est impossible de passer des paires de substitution non valides. Les fonctions XQuery requièrent une entité de caractère unique pour le caractère de niveau supérieur. Ces fonctions génèrent une erreur si les entités de caractère pour les caractères de paire de substitution sont fournies.

• Importez des valeurs externes à l’aide de sql:column ou sql:variable. En utilisant ces méthodes, il est possible d'introduire des paires de substitution non valides ou partielles.

Fonctions et opérateurs XQuery affectés

Les fonctions et opérateurs XQuery suivants gèrent désormais correctement les paires de substitution UTF-16 dans SQL Server 2012 :

• fn:string-length. Toutefois, si une paire de substitution non valide ou partielle est passée en tant qu’argument, le comportement de longueur de chaîne n’est pas défini.

• fn:substring.

• fn:contains. Toutefois, si une paire de substitution partielle est passée en tant que valeur, les contient peuvent retourner des résultats inattendus, car il peut trouver la paire de substitution partielle contenue dans une paire de substituts bien formée.

• fn:concat. Toutefois, si une paire de substitution partielle est passée en tant que valeur, concat peut produire des paires de substitution incorrectes ou des paires de substitution partielles.

• Opérateurs de comparaison et clause order by . Les opérateurs de comparaison incluent +, <, , = <, eq>, , gtltle, et .ge>

Appels de requête distribuée à une procédure système

Les appels de requête distribués via OPENQUERY à certaines procédures système échouent lorsqu’ils sont appelés d’un serveur SQL Server 2012 à un autre. Cela se produit lorsque le moteur de base de données ne peut pas détecter les métadonnées d’une procédure. Par exemple : SELECT * FROM OPENQUERY(..., 'EXEC xp_loginfo').

Niveau d'isolement et sp_reset_connection

Le niveau d'isolement pour les connexions est géré par les pilotes clients de la manière suivante :

• Tous les pilotes natifs (SNAC, MDAC, ODBC) définissent le niveau d'isolement (selon les paramètres de l'application) lors de l'exécution de sp_reset_connection.

• Pour ADO.NET, vous obtiendrez essentiellement un niveau d'isolement aléatoire en fonction de la connexion obtenue à partir du pool (si l'application utilise un niveau d'isolement différent). Étant donné que le pool ADO.NET peut recycler les connexions en interne de façon transparente, vous ne pouvez pas prédire quelle connexion vous obtiendrez du pool.

• Avec le pilote JDBC, le comportement est le même que pour ADO.NET

  L'application doit toujours définir explicitement le niveau d'isolement après l'ouverture de la connexion pour obtenir ce qu'elle veut.

  Comme la connexion JDBC peut être regroupée dans un pool, il est possible que l'application obtienne un niveau d'isolement aléatoire sans le savoir.

Pour maintenir la compatibilité descendante, ce nouveau comportement concerne uniquement les clients récents (à partir de TDS 7.4).

Backward Compatibility

Le nouveau comportement dépend du niveau de compatibilité

Les fonctions et opérateurs suivants illustrent le nouveau comportement décrit ci-dessus uniquement lorsque le niveau de compatibilité est supérieur ou égal à 110 :

• fn:contains.

• fn:concat.

• opérateurs de comparaison et clause order by

Le nouveau comportement dépend de l'URI d'espace de noms par défaut des fonctions

Les fonctions suivantes illustrent le nouveau comportement décrit ci-dessus uniquement lorsque l’URI d’espace de noms par défaut correspond à l’espace de noms dans la recommandation finale, http://www.w3.org/2005/xpath-functionsc’est-à-dire . Lorsque le niveau de compatibilité est égal ou supérieur à 110, SQL Server 2012 lie par défaut l’espace de noms de fonction par défaut à cet espace de noms. Toutefois ces fonctions illustrent le nouveau comportement lorsque cet espace de noms est utilisé quel que soit le niveau de compatibilité.

• fn:string-length

• fn:substring

Modifications avec rupture dans SQL Server 2008/SQL Server 2008 R2

Cette section contient les modifications cassants introduites dans SQL Server 2008. Aucune modification n’a été introduite dans SQL Server 2008 R2.

Classements

CLR (Common Language Runtime)

Vues de gestion dynamique

Erreurs et événements

Showplan

Transact-SQL

XQuery

Connecting

Changements essentiels apportés à SQL Server 2005

Nous accumulons et conservons la documentation pour les versions très anciennes de Microsoft SQL Server dans un ensemble de pages web d’archive. Les pages web archivées ne sont pas traitées par les moteurs de recherche tels que Bing.com et Google.com. Mais vous pouvez voir ces archives à l’adresse de notre docs versions précédentes/ :

• https://docs.microsoft.com/previous-versions/sql/

Ces archives incluent la documentation pour au moins les versions antérieures suivantes :

• SQL Server 2014
• SQL Server 2012
• SQL Server 2008 R2
• SQL Server 2008
• SQL Server 2005

SQL Server documentation 2014 a été archivée et n’est plus traitée par les moteurs de recherche. Les articles de 2014 se déclarent maintenant avec NOINDEX et NOFOLLOW.

La dernière version de SQL Server, ainsi que d’autres versions récentes, est documentée ici.

Voir aussi

Fonctionnalités du moteur de base de données déconseillées dans SQL Server 2014
Changements de comportement des fonctionnalités du moteur de base de données de SQL Server 2014
Discontinued Database Engine Functionality in SQL Server 2014 (Fonctionnalités du moteur de base de données non disponibles dans SQL Server 2014)
Compatibilité descendante du moteur de base de données SQL Server
Niveau de compatibilité ALTER DATABASE (Transact-SQL)
Dernières modifications apportées aux fonctionnalités des outils d'administration dans SQL Server 2014