Partager via

Changements de comportement des fonctionnalités du moteur de base de données de SQL Server 2014

  • Article

Cette rubrique décrit les changements de comportement dans le moteur de base de données. Les changements de comportement affectent le fonctionnement ou l’interaction des fonctionnalités dans SQL Server 2014 par rapport aux versions antérieures de SQL Server.

Changements de comportement dans SQL Server 2014

Dans les versions antérieures de SQL Server, les requêtes sur un document XML qui contient des chaînes sur une certaine longueur (plus de 4 020 caractères) peuvent retourner des résultats incorrects. Dans SQL Server 2014, ces requêtes retournent les résultats corrects.

Changements de comportement dans SQL Server 2012

Découverte des métadonnées

Les améliorations apportées au moteur de base de données à compter de SQL Server 2012 permettent à SQLDescribeCol d’obtenir des descriptions plus précises des résultats attendus que ceux retournés par SQLDescribeCol dans les versions précédentes de SQL Server. Pour plus d’informations, consultez Découverte des métadonnées.

L’option SET FMTONLY permettant de déterminer le format d’une réponse sans exécuter la requête est remplacée par sp_describe_first_result_set (Transact-SQL),sp_describe_undeclared_parameters (Transact-SQL),sys.dm_exec_describe_first_result_set (Transact-SQL) et sys.dm_exec_describe_first_result_set_for_object (Transact-SQL).

Modifications du comportement dans le script d'une tâche SQL Server Agent

À compter de SQL Server 2012, si vous créez un travail en copiant le script à partir d’un travail existant, le nouveau travail peut affecter par inadvertance le travail existant. Pour créer un travail à l’aide du script à partir d’un travail existant, supprimez manuellement le paramètre @schedule_uid qui est généralement le dernier paramètre de la section qui crée la planification de travail dans le travail existant. Vous créez ainsi une planification indépendante pour le nouveau travail sans affecter les travaux existants.

Assemblage de constantes pour les Fonctions CLR définies par l'utilisateur et les méthodes

À compter de SQL Server 2012, les objets CLR définis par l’utilisateur suivants sont désormais pliables :

  • Fonctions CLR définies par l'utilisateur à valeur scalaire déterministes.
  • Méthodes déterministes des types CLR définis par l'utilisateur.

Cette amélioration s'efforce d'améliorer les performances lorsque ces fonctions ou méthodes sont appelées plusieurs fois avec les mêmes arguments. Toutefois, cette modification peut générer des résultats inattendus lorsque des fonctions ou méthodes non déterministes ont été marquées comme étant déterministes par erreur. Le déterminisme d'une fonction ou d'une méthode CLR est indiqué par la valeur de la propriété IsDeterministic de SqlFunctionAttribute ou de SqlMethodAttribute.

Le comportement de la méthode de STEnvelope() a changé avec les types spatiaux vides

Le comportement de la STEnvelope méthode avec des objets vides est désormais cohérent avec celui d’autres méthodes spatiales SQL Server.

Dans SQL Server 2008, la STEnvelope méthode a retourné les résultats suivants lorsqu’elle est appelée avec des objets vides :

SELECT geometry::Parse('POINT EMPTY').STEnvelope().ToString()  
-- returns POINT EMPTY  
SELECT geometry::Parse('LINESTRING EMPTY').STEnvelope().ToString()  
-- returns LINESTRING EMPTY  
SELECT geometry::Parse('POLYGON EMPTY').STEnvelope().ToString()  
-- returns POLYGON EMPTY

Dans SQL Server 2012, la STEnvelope méthode retourne désormais les résultats suivants lorsqu’elle est appelée avec des objets vides :

SELECT geometry::Parse('POINT EMPTY').STEnvelope().ToString()  
-- returns GEOMETRYCOLLECTION EMPTY  
SELECT geometry::Parse('LINESTRING EMPTY').STEnvelope().ToString()  
-- returns GEOMETRYCOLLECTION EMPTY  
SELECT geometry::Parse('POLYGON EMPTY').STEnvelope().ToString()  
-- returns GEOMETRYCOLLECTION EMPTY

Pour déterminer si un objet spatial est vide, appelez la méthode STIsEmpty (geometry Data Type).

La fonction LOG dispose d'un nouveau paramètre facultatif

La LOG fonction a désormais un paramètre de base facultatif. Pour plus d’informations, consultez LOG (Transact-SQL).

Le calcul des statistiques pour les opérations d'index partitionnés a changé

Dans SQL Server 2014, les statistiques ne sont pas créées en analysant toutes les lignes de la table lors de la création ou de la reconstruction d’un index partitionné. Au lieu de cela, l’optimiseur de requête utilise l’algorithme d’échantillonnage par défaut pour générer des statistiques. Après la mise à niveau d'une base de données avec des index partitionnés, vous pouvez remarquer une différence dans les données d'histogramme pour ces index. Cette modification du comportement peut ne pas affecter les performances des requêtes. Pour obtenir des statistiques sur les index partitionnés en analysant toutes les lignes de la table, utilisez CREATE STATISTICS ou UPDATE STATISTICS avec la clause FULLSCAN.

La conversion de type de données par la méthode XML value a changé

Le comportement interne de la méthode value de type de données xml a changé. Cette méthode effectue une XQuery sur le xml et retourne une valeur scalaire du type de données SQL Server spécifié. Le type xs doit être converti en type de données SQL Server. Auparavant, la value méthode convertissait en interne la valeur source en xs:string, puis convertissait la xs:string en type de données SQL Server. Dans SQL Server 2014, la conversion en xs:string est ignorée dans les cas suivants :

Type de données XS source Type de données SQL Server de destination
byte

short

int

entier

long

unsignedByte

unsignedShort

unsignedInt

unsignedLong

positiveInteger

nonPositiveInteger

negativeInteger

nonNegativeInteger		 TINYINT

SMALLINT

int

bigint

Décimal

numeric
Décimal Décimal

numeric
float real
double float

Le nouveau comportement améliore les performances lorsque la conversion intermédiaire peut être ignorée. Toutefois, lorsque la conversion des types de données échoue, des messages d'erreur différents de ceux qui ont été générés lors de la conversion à partir de la valeur xs:string intermédiaire s'affichent. Par exemple, si la méthode value n'a pas réussi à convertir la valeur int 100 000 en smallint, le message d'erreur précédent était :

The conversion of the nvarchar value '100000' overflowed an INT2 column. Use a larger integer column.

Dans SQL Server 2014, sans la conversion intermédiaire en xs:string, le message d’erreur est :

Arithmetic overflow error converting expression to data type smallint.

Changement de comportement de sqlcmd.exe en mode XML

Il y a des changements de comportement si vous utilisez sqlcmd.exe en mode XML (commande:XML ON) lors de l’exécution d’une commande SELECT * à partir de T FOR XML ....

Message modifié par DBCC CHECKIDENT

Dans SQL Server 2012, le message retourné par la commande DBCC CHECKIDENT a changé uniquement lorsqu’il est utilisé avec RESEED new_reseed_value pour modifier la valeur d’identité actuelle. Le nouveau message est « Vérification des informations d’identité : valeur d’identité actuelle «< valeur> d’identité actuelle ». Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur, contactez l'administrateur système. »

Dans les versions antérieures, le message est « Vérification des informations d’identité : valeur d’identité actuelle «< valeur> d’identité actuelle », valeur de colonne actuelle « valeur> de colonne actuelle ».< L’exécution de DBCC s’est terminée. Si DBCC a imprimé des messages d’erreur, contactez votre administrateur système. » Le message est inchangé quand DBCC CHECKIDENT est spécifié avec NORESEED, sans second paramètre ou sans valeur réensée. Pour plus d’informations, consultez DBCC CHECKIDENT (Transact-SQL).

Le comportement de la fonction exist() la fonction sur le type de données XML a changé

Le comportement de la fonction a changé lors de la exist() comparaison d’un type de données XML avec une valeur null à 0 (zéro). Prenons l’exemple suivant :

DECLARE @test XML;  
SET @test = null;  
SELECT COUNT(1) WHERE @test.exist('/dogs') = 0;

Dans les versions antérieures, cette comparaison retournait 1 (true) ; maintenant, elle retourne 0 (zéro, false).

Les comparaisons suivantes n'ont pas changé :

DECLARE @test XML;  
SET @test = null;  
SELECT COUNT(1) WHERE @test.exist('/dogs') = 1; -- 0 expected, 0 returned  
SELECT COUNT(1) WHERE @test.exist('/dogs') IS NULL; -- 1 expected, 1 returned

Voir aussi

Changements essentiels dans les fonctionnalités du moteur de base de données de SQL Server 2014
Fonctionnalités du moteur de base de données déconseillées dans 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)
Niveau de compatibilité ALTER DATABASE (Transact-SQL)