Exporter (0) Imprimer
Développer tout
Cet article a fait l'objet d'une traduction manuelle. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte. Informations supplémentaires.
Traduction
Source

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

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 2014 par rapport aux versions précédentes de SQL Server.

Dans les versions précédentes de SQL Server, les requêtes sur un document XML contenant des chaînes dépassant une certaine longueur (plus de 4020 caractères) peuvent contenir des résultats incorrects. Dans SQL Server 2014, ces requêtes retournent les résultats corrects.

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ées 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 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 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 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

Integer

long

unsignedByte

unsignedShort

UnsignedInt

unsignedLong

positiveInteger

nonPositiveInteger

negativeInteger

nonNegativeInteger

tinyint

smallint

int

bigint

decimal

numeric

decimal

decimal

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 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 Manageability Enhancements (Database Engine).

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
Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

AJOUTER
Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2014 Microsoft