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

Cette rubrique décrit les changements de comportement dans le moteur de base de données. Les modifications de comportement affectent le mode de fonctionnement ou d'interaction des fonctionnalités dans SQL Server 2012 par rapport aux versions précédentes de SQL Server.

Découverte des métadonnées

Les améliorations du moteur de base de données dès SQL Server 2012 permettent à SQLDescribeCol d'obtenir des descriptions plus exactes 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 pour la détermination du format d'une réponse sans exécuter réellement 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

Dans SQL Server 2012, si vous créez un travail en copiant le script d'un travail existant, le nouveau travail peut affecter par inadvertance le travail existant. Pour créer un travail en utilisant le 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. 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

Dans SQL Server 2012, les objets CLR définis par l'utilisateur suivants peuvent maintenant être assemblés :

• 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 méthode STEnvelope avec des objets vides est maintenant compatible avec le comportement d'autres méthodes spatiales SQL Server .

Dans SQL Server 2008, la méthode STEnvelope retournait les résultats suivants lorsqu'elle était 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 méthode STEnvelope retourne maintenant 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 (type de données geometry).

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

La fonction LOG a maintenant un paramètre 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 2012, 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 XML value a changé

Le comportement interne de la méthode value de type de données xml a changé. Cette méthode exécute une requête 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. Précédemment, la méthode value convertissait en interne la valeur source en type xs:string, puis convertissait le type xs:string en type de données SQL Server . Dans SQL Server 2012, la conversion en xs:string est ignorée dans les cas suivants :

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 2012, sans 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 existe des différences de comportement si vous utilisez sqlcmd.exe avec le mode XML (commande :XML ON) lors de l'exécution de SELECT * from T FOR XML …. Pour plus d'informations, consultez Améliorations de la gestion (moteur de base de données).

Message modifié par DBCC CHECKIDENT

Dans SQL Server 2012, le message retourné par la commande DBCC CHECKIDENT change 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 '<current identity value>' ». 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 était « Vérification des informations d'identité : valeur d'identité actuelle '<current identity value>', valeur de colonne actuelle '<current column value>' ». Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur, contactez l'administrateur système. » Le message est inchangé lorsque 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() la fonction sur le type de données XML a changé

Le comportement de la fonction exist() a changé lors de la 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

Référence

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

Fonctionnalités du moteur de base de données déconseillées dans SQL Server 2012

Fonctionnalités du moteur de base de données supprimées dans SQL Server 2012

Niveau de compatibilité ALTER DATABASE (Transact-SQL)