Partager via

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

Cette rubrique décrit les modifications de comportement dans le moteur de base de données. Les modifications 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 4020 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 à partir 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 La découverte des métadonnées.

L’option SET FMTONLY pour déterminer le format d’une réponse sans réellement 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 apportées au comportement dans l’écriture de scripts 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 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 du travail dans le travail existant. Cela crée une planification indépendante pour le nouveau travail sans affecter les travaux existants.

Pliage constant pour les fonctions et méthodes clR User-Defined

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

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

Cette amélioration vise à améliorer les performances lorsque ces fonctions ou méthodes sont appelées plusieurs fois avec les mêmes arguments. Toutefois, cette modification peut entraîner des résultats inattendus lorsque des fonctions ou méthodes non déterministes ont été marquées comme déterministes en cas d’erreur. Le déterminisme d’une fonction ou d’une méthode CLR est indiqué par la valeur de la propriété de SqlFunctionAttribute ou SqlMethodAttribute.

Comportement de la méthode STEnvelope() a changé avec des types spatiaux vides

Le comportement de la STEnvelope méthode avec des objets vides est désormais cohérent avec le comportement 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).

Log Function a un nouveau paramètre facultatif

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

Calcul des statistiques lors des 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 lorsqu’un index partitionné est créé ou reconstruit. 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 de la valeur XML a changé

Le comportement interne de la value méthode du type de xml données a changé. Cette méthode effectue une requête XQuery sur le code 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 a converti en interne la valeur source en xs :string, puis converti le 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 source XS Type de données SQL Server de destination
octet

court

Int

entier

long

octet non signé

entier court non signé

unsignedInt

unsignedLong

positiveInteger

nonPositiveInteger

negativeInteger

entierNonNégatif		 tinyint

smallint

Int

bigint

décimal

numérique
décimal décimal

numérique
flotter réel
double flotter

Le nouveau comportement améliore les performances lorsque la conversion intermédiaire peut être ignorée. Toutefois, lorsque les conversions de type de données échouent, vous voyez des messages d’erreur différents de ceux qui ont été déclenchés lors de la conversion à partir de la valeur xs :string intermédiaire. Par exemple, si la méthode valeur n’a pas pu convertir la int valeur 100000 en un 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 conversion intermédiaire en xs :string, le message d’erreur est :

Arithmetic overflow error converting expression to data type smallint.

Changement de comportement sqlcmd.exe en mode XML

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

Message révisé DBCC CHECKIDENT

Dans SQL Server 2012, le message retourné par la commande DBCC CHECKIDENT n’a changé que 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 a imprimé des messages d’erreur, contactez votre 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 ». Exécution DBCC terminée. Si DBCC a imprimé des messages d’erreur, contactez votre administrateur système. » Le message n’est pas modifié lorsqu’il DBCC CHECKIDENT est spécifié avec NORESEED, sans deuxième paramètre ou sans valeur reseed. Pour plus d’informations, consultez DBCC CHECKIDENT (Transact-SQL).

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

Le comportement de la fonction exist() a changé lorsqu'on compare le type de données XML avec une valeur nulle à 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 retourne 1 (true) ; maintenant, cette comparaison 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 dépréciées du moteur de base de données dans SQL Server 2014
Fonctionnalités du moteur de base de données abandonnées dans SQL Server 2014
Niveau de compatibilité ALTER DATABASE (Transact-SQL)

  • Last updated on