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

Article
12/15/2008

Mis à jour : 17 juillet 2006

Cette rubrique décrit les changements de comportement de certaines fonctionnalités du moteur de base de données dans Microsoft SQL Server 2005 par rapport aux versions précédentes de SQL Server.

Sauvegarde et récupération

Lorsque vous restaurez une base de données existante, SQL Server 2005 vous demande d'effectuer une sauvegarde de fichier journal après défaillance avant de restaurer la base de données selon le mode de restauration complète ou utilisant les journaux de transactions. Si vous tentez de restaurer une base de données avant d'effectuer une sauvegarde du fichier journal après défaillance, vous recevez une erreur, sauf si l'instruction RESTORE contient une clause WITH REPLACE ou WITH STOPAT. Pour plus d'informations, consultez Sauvegardes de fichier journal après défaillance.

Curseurs

Le tableau suivant donne la liste des conversions de curseur implicites qui se produisent dans SQL Server 2000 mais pas dans SQL Server 2005. Pour contourner ce problème, demandez un type de curseur spécifique plutôt que de laisser agir la conversion implicite.

Condition	Dans SQL Server 2000, le curseur est converti de	En
La requête contient la fonction tabulaire inline.	Dynamique/jeu de clés	Statique
La requête référence un objet distant.	Curseur à avance rapide	Jeu de clés
La requête ne contient pas de tables.	Curseur à avance rapide	Statique
La requête contient une fonction table.	Curseur à avance rapide	Statique
La requête contient une table dérivée.	Curseur à avance rapide	Statique
La requête contient une fonction table à instructions multiples.	Dynamique Jeu de clés	Jeu de clés vers statique Statique
La requête contient une table virtuelle.	Dynamique/jeu de clés	Statique
La requête contient une vue avec TOP.	Curseur à avance rapide	Statique
La requête contient des vues partitionnées qui peuvent être mises à jour.	Curseur à avance rapide	Statique
La requête de curseur d'API contient une vue indexée à chemin d'accès unique, mais pas au niveau table de base.	Jeu de clés	Statique
La requête de curseur d'API contient une table sans index cluster ni clé unique.	Jeu de clés	Statique
L'ensemble de résultats du curseur d'API contient une colonne text, ntext ou image.	Curseur à avance rapide	Dynamique

SQL Server 2005 ne prend pas en charge la génération de curseurs Transact-SQL pilotés par jeu de clés ou statiques de façon asynchrone. Les opérations de curseur Transact-SQL, comme OPEN ou FETCH, s'effectuent généralement par lots ; c'est pourquoi la génération asynchrone de curseurs Transact-SQL n'est pas nécessaire. SQL Server 2005 prend toujours en charge les curseurs de serveur d'API asynchrones pilotés par jeu de clés ou statiques lorsqu'une opération OPEN à faible latence pose un problème en raison du nombre de boucles de clients pour chaque opération de curseur.

Dans SQL Server 2005, lorsqu'un curseur dynamique est déclaré sur une table sans index uniques, et lorsqu'une ligne est supprimée en dehors du curseur, une actualisation ultérieure du curseur récupère un espace réservé pour la ligne contenant des données NULL. Dans les anciennes versions de SQL Server, le curseur ne renvoyait pas la ligne concernée.

Dans SQL Server 2005, si différentes déclarations de curseur sont possibles au moyen de la logique conditionnelle dans un lot ou une procédure stockée, les instructions INSERT, UPDATE et DELETE exécutées avec le curseur provoquent une recompilation. Dans SQL Server 2000, ces instructions ne provoquaient pas de recompilation.

Dans l'exemple suivant, l'instruction UPDATE provoque une recompilation du module.

IF(@some_condition=1)
   DECLARE c CURSOR FOR 
      SELECT region FROM db.dbo.mytable ORDER BY lastname
ELSE
   DECLARE c CURSOR FOR 
      SELECT postalcode FROM db.dbo.mytable ORDER BY firstname
...
FETCH NEXT FROM c
...
UPDATE db.dbo.mytable 
   SET  firstname='a' WHERE CURRENT OF c

Pour éviter la recompilation, réécrivez le code de cette façon :

IF (@some_condition=1)
BEGIN
   DECLARE c CURSOR FOR 
     SELECT region FROM db.dbo.mytable ORDER BY lastname
   FETCH NEXT FROM c
   UPDATE db.dbo.mytable 
     SET  firstname='a' WHERE CURRENT OF c
END
ELSE
BEGIN
  DECLARE c CURSOR FOR 
    SELECT postalcode FROM db.dbo.mytable ORDER BY firstname
  FETCH NEXT FROM c
  UPDATE db.dbo.mytable 
    SET  firstname='a' WHERE CURRENT OF c
END

Dans SQL Server 2005, les verrous de défilement de curseur bénéficient d'une mise à niveau du verrou S (partagé) vers U (mise à jour), sauf si un indicateur (hint) de verrou supérieur est spécifié dans la requête. SQL Server 2000 ajoute automatiquement un indicateur de verrou U pour les curseurs à verrou de défilement. Ce comportement dans SQL Server 2005 améliore la concurrence, mais augmente les risques de blocage (message 1205) pour les curseurs concurrents. Utilisez l'indicateur UPDLOCK pour obtenir le comportement souhaité. Pour plus d'informations, consultez Indicateur de table (T-SQL).

Dans SQL Server 2000, lorsqu'une valeur de colonne ou de ligne apparaissant plusieurs fois dans un tampon d'extraction de curseur était actualisée, les autres occurrences risquaient de ne pas refléter cette mise à jour en raison du tampon d'extraction ou de la position des lignes dans le tampon. Dans SQL Server 2005, les lignes situées dans le tampon d'extraction sont actualisées de telle façon que les valeurs sont toujours cohérentes, quelle que soit la taille du tampon d'extraction ou la position des lignes.

Dans SQL Server 2000, les curseurs qui impliquent une instruction UNION ALL renvoient par erreur des informations sur la possibilité de mise à jour en fonction du premier jeu de l'UNION. C'est pourquoi certains curseurs sont déclarés actualisables alors qu'ils ne le sont pas. SQL Server 2005 déclare les résultats de UNION ALL comme calculés, et par conséquent non actualisables. Si toutes les lignes de curseur proviennent d'une seule table ou vue, vous pouvez définir un curseur qui soit actualisable en remplaçant dans la requête la clause UNION par des clauses IN ou OR.

Dans SQL Server 2000, lorsque l'option CURSOR_CLOSE_ON_COMMIT est activée, tous les curseurs d'une connexion sont fermés lors de la validation de la transaction. Dans SQL Server 2005, seuls les curseurs qui sont ouverts dans la transaction en cours sont fermés lors de la validation de cette transaction. Les curseurs qui sont ouverts avant le début de la transaction demeurent ouverts.

SQL Server 2000 autorise certaines déclarations de curseurs non valides et les convertit en d'autres types de curseurs. SQL Server 2005 n'autorise pas les déclarations non valides. Par exemple, un curseur qui demande une mise à jour et une insensibilité n'est pas valide dans SQL Server 2005 et échoue avec une erreur.

Bases de données, données et fichiers journaux

Comportement de SQL Server 2000	Comportement de SQL Server 2005
L'option de base de données AUTO_CLOSE est un processus synchrone qui peut dégrader les performances lors de l'accès à la base de données par une application qui ouvre et ferme de façon répétée des connexions au moteur de base de données.	Le processus AUTO_CLOSE est asynchrone. L'ouverture et la fermeture répétées de la base de données n'influe plus sur les performances.
La taille des fichiers placés sur les partitions brutes n'augmente pas automatiquement. Ainsi, les paramètres MAXSIZE et FILEGROWTH ne sont pas nécessaires si os_file_name spécifie une partition brute.	Les fichiers placés sur les partitions brutes peuvent croître automatiquement. Vous pouvez spécifier les paramètres MAXSIZE et FILEGROWTH.
Les autorisations ne sont pas définies sur les données et les journaux de chaque base de données.	Des autorisations sont définies sur les données et les journaux chaque fois que les opérations suivantes sont appliquées à la base de données : CréationModification pour ajouter un nouveau fichier AttachementSauvegarde DétachéeRestaurée

L'option de base de données AUTO_CLOSE est un processus synchrone qui peut dégrader les performances lors de l'accès à la base de données par une application qui ouvre et ferme de façon répétée des connexions au moteur de base de données.

Le processus AUTO_CLOSE est asynchrone. L'ouverture et la fermeture répétées de la base de données n'influe plus sur les performances.

La taille des fichiers placés sur les partitions brutes n'augmente pas automatiquement. Ainsi, les paramètres MAXSIZE et FILEGROWTH ne sont pas nécessaires si os_file_name spécifie une partition brute.

Les fichiers placés sur les partitions brutes peuvent croître automatiquement. Vous pouvez spécifier les paramètres MAXSIZE et FILEGROWTH.

Les autorisations ne sont pas définies sur les données et les journaux de chaque base de données.

Des autorisations sont définies sur les données et les journaux chaque fois que les opérations suivantes sont appliquées à la base de données :

CréationModification pour ajouter un nouveau fichier

AttachementSauvegarde

DétachéeRestaurée

Les autorisations empêchent les fichiers d'être accidentellement falsifiés s'ils résident dans un répertoire doté d'autorisations d'ouverture. Pour plus d'informations, consultez Sécurisation des fichiers de données et des fichiers journaux.

ms143359.note(fr-fr,SQL.90).gif Remarque :

Microsoft SQL Server 2005 Express Edition ne définit pas d'autorisations sur les fichiers de données et les journaux.

Serveurs liés et requêtes distribuées

Un serveur lié qui a été défini avec le nom de fournisseur « SQLOLEDB » sera modifié en « SQLNCLI » (Fournisseur OLE DB de SQL Native Client) lors de la mise à niveau. La vue de compatibilité sys.sysservers présente les serveurs liés qui utilisent « SQLNCLI » en tant que « SQLOLEDB ». L'affichage catalogue SQL Server 2005 sys.servers présente les serveurs liés qui utilisent « SQLNCLI » en tant que « SQLNCLI ».

Les requêtes hétérogènes et l'utilisation de fournisseurs OLE DB ne sont pas prises en charge lorsque SQL Server s'exécute en mode fibre. Le mode fibre est activé lorsque l'option de configuration avancée lightweight pooling est définie à 1.

Le fournisseur OLE DB de SQL Native Client ne peut pas être instancié hors processus.

Les messages d'avertissement en provenance d'un serveur lié dans SQL Server 2005 ne sont pas propagés vers le client. Les classes les plus significatives de tels avertissements sont les suivantes :

Les avertissements compatibles ANSI prévenant que les valeurs NULL ont été éliminées dans un calcul agrégé.
Les avertissements de débordement arithmétique.

Par exemple, l'instruction Transact-SQL suivante peut générer un message d'avertissement si la col1 contient des valeurs NULL.

SELECT SUM(col1)
FROM <Table>
GROUP BY col2

Dans SQL Server 2000 et versions antérieures, les serveurs liés propageaient le message d'avertissement vers le client. Dans SQL Server 2005, ils ne le font pas.

Dans SQL Server 2000, lorsque l'exécution d'une procédure stockée distante échoue en raison d'erreurs au moment de la compilation telles qu'une liaison de paramètres incorrecte, la valeur/l'état de retour est défini sur 0. Lorsque ceci se produit dans SQL Server 2005, la valeur/l'état de retour est défini à NULL.

Architecture du processeur de requêtes

L'emploi de valeurs de paramètres durant la recompilation diffère entre SQL Server 2000 et SQL Server 2005 pour les lots envoyés sous les formes suivantes :

Procédures stockées
Emploi de sp_executesql
Instructions préparées

Lorsque SQL Server 2000 recompile ces lots, il utilise les valeurs de paramètres par lesquelles les lots sont appelés dans le cadre de la recompilation. Lorsque SQL Server 2005 recompile ces requêtes, il utilise les valeurs de paramètres telles qu'elles sont juste avant l'instruction qui provoque la recompilation. Ces valeurs peuvent être différentes de celles qui ont été à l'origine passées dans le lot. Pour plus d'informations, consultez Réutilisation des paramètres et des plans d'exécution.

Sécurité

Caractéristique	Comportement de SQL Server 2000	Comportement de SQL Server 2005
GRANT ALL	Accorde toutes les autorisations applicables.	La possibilité d'accorder une autorisation ALL sur les objets et les instructions a été abandonnée. Lorsque GRANT ALL est exécuté, voici ce qui se produit : La commande réussit, mais seules les autorisations qu'il est possible d'accorder dans SQL Server 2000 sont accordées à l'utilisateur. Vous recevez le message suivant : « L'autorisation ALL est désapprouvée et conservée uniquement à des fins de compatibilité. Cela NE concerne PAS les autorisations ALL définies sur l'entité. » SQL Server 2005 propose des autorisations supplémentaires de portées diverses, qui peuvent être utilisées pour gérer les autorisations des utilisateurs. Par exemple, l'instruction CONTROL permet d'accorder des autorisations de type appartenance sur un objet.
Comparaisons de mots de passe	SQL Server 2000 gère deux versions de chaque mot de passe de connexion SQL Server. L'un d'eux est le mot de passe réel fourni par l'utilisateur, et l'autre le mot de passe converti par SQL Server en lettres majuscules. Ceci permet de valider les mots de passe sans tenir compte de la casse. Si ce comportement est pratique pour les utilisateurs, il facilite les attaques par détection de mot de passe en réduisant le nombre de mots de passe possibles.	Seul le mot de passe réel est stocké. Un mot de passe entré par un utilisateur doit correspondre au mot de passe stocké par le serveur. Si un mot de passe ne correspond pas à celui qui est stocké dans SQL Server, la connexion échoue. Si vous oubliez les majuscules et minuscules précises, vous devez redéfinir un mot de passe.
Modification de la langue par défaut d'un compte sa	La langue par défaut du compte SQL Server sa est celle sélectionnée au cours de l'installation ou de la mise à niveau. Dans les versions antérieures de Microsoft SQL Server, l'exécution de sp_configure pour modifier la langue par défaut du serveur met aussi à jour la langue par défaut du compte sa.	Pour modifier la langue par défaut du compte sa dans SQL Server 2005, vous devez exécuter la procédure stockée sp_defaultlanguage, exécuter la commande DBCC FREESYSTEMCACHE, puis démarrer une nouvelle session. L'exécution de sp_configure pour modifier la langue par défaut du serveur ne met pas à jour la langue par défaut du compte sa.

GRANT ALL

Accorde toutes les autorisations applicables.

La possibilité d'accorder une autorisation ALL sur les objets et les instructions a été abandonnée. Lorsque GRANT ALL est exécuté, voici ce qui se produit :

La commande réussit, mais seules les autorisations qu'il est possible d'accorder dans SQL Server 2000 sont accordées à l'utilisateur.
Vous recevez le message suivant : « L'autorisation ALL est désapprouvée et conservée uniquement à des fins de compatibilité. Cela NE concerne PAS les autorisations ALL définies sur l'entité. »

SQL Server 2005 propose des autorisations supplémentaires de portées diverses, qui peuvent être utilisées pour gérer les autorisations des utilisateurs. Par exemple, l'instruction CONTROL permet d'accorder des autorisations de type appartenance sur un objet.

Comparaisons de mots de passe

SQL Server 2000 gère deux versions de chaque mot de passe de connexion SQL Server. L'un d'eux est le mot de passe réel fourni par l'utilisateur, et l'autre le mot de passe converti par SQL Server en lettres majuscules. Ceci permet de valider les mots de passe sans tenir compte de la casse. Si ce comportement est pratique pour les utilisateurs, il facilite les attaques par détection de mot de passe en réduisant le nombre de mots de passe possibles.

Seul le mot de passe réel est stocké. Un mot de passe entré par un utilisateur doit correspondre au mot de passe stocké par le serveur. Si un mot de passe ne correspond pas à celui qui est stocké dans SQL Server, la connexion échoue. Si vous oubliez les majuscules et minuscules précises, vous devez redéfinir un mot de passe.

Modification de la langue par défaut d'un compte sa

La langue par défaut du compte SQL Server sa est celle sélectionnée au cours de l'installation ou de la mise à niveau.

Dans les versions antérieures de Microsoft SQL Server, l'exécution de sp_configure pour modifier la langue par défaut du serveur met aussi à jour la langue par défaut du compte sa.

Pour modifier la langue par défaut du compte sa dans SQL Server 2005, vous devez exécuter la procédure stockée sp_defaultlanguage, exécuter la commande DBCC FREESYSTEMCACHE, puis démarrer une nouvelle session. L'exécution de sp_configure pour modifier la langue par défaut du serveur ne met pas à jour la langue par défaut du compte sa.

Procédures stockées système

Les tableaux qui suivent donnent la liste des changements apportés aux paramètres dans les procédures stockées système du moteur de base de données.

Procédure stockée	Paramètre	Description de la modification
sp_bindefault	@objname	La taille a changé, de nvarchar(517) à nvarchar(776).
sp_bindrule	@objname	La taille a changé, de nvarchar(517) à nvarchar(776).
sp_changeobjectowner	@objname	La taille a changé, de nvarchar(517) à nvarchar(776).
sp_detach_db	@keepfulltextindexfile	La taille a changé, de nvarchar(517) à nvarchar(776).
sp_fulltext_service	@action	La taille a changé, de varchar(20) à nvarchar(100).
sp_fulltext_service	@value	Le type de données a changé, de int à sql_variant.
sp_getapplock	@DbPrincipal	Paramètre ajouté.
sp_releaseapplock	@DbPrincipal	Paramètre ajouté.
sp_setapprole	@fCreateCookie	Paramètre ajouté.
sp_setapprole	@cookie	Paramètre ajouté.
sp_settriggerorder	@stmttype	La taille a changé, de varchar(10) à varchar(50).
sp_settriggerorder	@namespace	Paramètre ajouté.
sp_sproc_columns	@fUsePattern	Paramètre ajouté.
sp_stored_procedures	@fUsePattern	Paramètre ajouté.
sp_table_privileges	@fUsePattern	Paramètre ajouté.
sp_table_privileges_ex	@fUsePattern	Paramètre ajouté.
sp_tables	@fUsePattern	Paramètre ajouté.
sp_tables_ex	@fUsePattern	Paramètre ajouté.

Tables et vues système

Le tableau qui suit donne la liste des changements apportés aux colonnes dans les tables et les vues système.

Table ou vue système	Colonne	Description de la modification
COLUMNS	ORDINAL_POSITION	Le type de données a changé, de smallint à int.
PARAMETERS	ORDINAL_POSITION	Type de données changé de smallint en int.
REFERENTIAL_CONSTRAINTS	MATCH_OPTION	La taille a changé, de varchar(4) à varchar(7). La valeur par défaut a changé, de « NONE » à « SIMPLE ».
REFERENTIAL_CONSTRAINTS	UPDATE_RULE	La taille a changé, de varchar(9) à varchar(11).
REFERENTIAL_CONSTRAINTS	DELETE_RULE	La taille a changé, de varchar(9) à varchar(11).
ROUTINE_COLUMNS	ORDINAL_POSITION	Type de données changé de smallint en int.
sysaltfiles	name	Le type de données a changé, de nchar(128) à sysname.
sysaltfiles	filename	Le type de données a changé, de nchar(260) à nvarchar(260).
sysconfigures	config	Type de données changé de smallint en int.
syscursorcolumns	data_type_sql	Type de données changé de smallint en int.
sysfiles	nom	Type de données changé de nchar(128) en sysname.
sysfiles	filename	Type de données changé de nchar(260) en nvarchar(260).
sysmessages	severity	Le type de données a changé, de smallint à tinyint.
sysperfinfo	cntr_value	Le type de données a changé, de int à bigint.
sysprocesses	waittime	Type de données changé de int en bigint.
sysprocesses	hostprocess	La taille a changé, de nchar(8) à nchar(10).
sysprocesses	request_id	Colonne ajoutée.
sysprotects	columns	La taille a changé, de varbinary(4000) à varbinary(8000).
sysservers	srvcollation	Le type de données a changé, de int à sysname.
sysservers	nonsqlsub	Colonnes ajoutées.
sysoledbusers	rmtpassword	Ne renvoie que la valeur NULL
sysindexes	keys	Retourne uniquement la valeur NULL.
sysindexes	statblob	Retourne uniquement la valeur NULL.
syscomments	compressed	Ne renvoie que 0.
sysdevices	size	Ne renvoie que 0.
sysobjects	schema_ver	Ne renvoie que 0.
sysremotelogins	status	Ne renvoie que 0.
sysservers	topologyx	Ne renvoie que 0.
sysservers	topologyy	Ne renvoie que 0.

Transact-SQL

Caractéristique	Comportement de SQL Server 2000	Comportement de SQL Server 2005
Utilitaire bcp	Un utilisateur doté des autorisations INSERT et SELECT sur une table peut se servir de l'utilitaire bcp pour charger en bloc les données dans cette table à l'aide de la commande suivante : `bcp <target table> in <datafile> -c -T` Par défaut, cette commande désactive les contraintes CHECK et les déclencheurs sur les tables cibles.	Pour exécuter l'utilitaire bcp, l'utilisateur doit posséder l'autorisation ALTER et des autorisations INSERT et SELECT sur les tables cibles si les contraintes CHECK et les déclencheurs sont désactivés durant le processus de copie en bloc. Après la mise à niveau vers SQL Server 2005, les commandes bcp des applications peuvent échouer en raison d'autorisations insuffisantes. Ce problème peut être traité de deux façons : en accordant l'autorisation ALTER TABLE à l'utilisateur sur toutes les tables qui sont affectées par le processus bcp ; en modifiant la commande bcp pour imposer explicitement les déclencheurs et les contraintes CHECK, comme dans la commande suivante : `bcp <target table> in <datafile> -c -T -h "CHECK_CONSTRAINTS, FIRE_TRIGGERS"`
Fonctions système intégrées	Chaque référence aux fonctions intégrées, comme NEWID et RAND, produit un résultat différent parce qu'elle est évaluée une fois pour chaque référence de requête externe.	Une requête externe peut faire de nombreuses références à des colonnes de vues ou de tables dérivées. Cependant, si ces colonnes sont définies en appelant des fonctions telles que NEWID et RAND, ces références multiples ont pour conséquence que la fonction n'est évaluée qu'une fois pour chaque appel réel dans la vue ou la table dérivée. Les références multiples à de telles colonnes dans une sous-requête n'entraînent pas que les fonctions soient évaluées plusieurs fois. Ceci vous permet de réutiliser la valeur produite par ces fonctions dans la sous-requête. Par exemple, dans SQL Server 2000, la requête suivante renvoie deux valeurs différentes. Dans SQL Server 2005, elle renvoie une seule valeur. `SELECT Column1, Column1 FROM ( SELECT RAND() Column1 FROM ( SELECT 1 c UNION SELECT 2 c ) s ) t`
BULK INSERT	BULK INSERT prend en charge la conversion de type chaîne en type décimal pour les chaînes représentant des valeurs numériques utilisant une notation scientifique.	Les conversions de type chaîne en type décimal utilisées dans BULK INSERT suivent les mêmes règles que la fonction Transact-SQL CONVERT. Cette fonction rejette les chaînes représentant des valeurs numériques qui utilisent une notation scientifique. C'est pourquoi BULK INSERT traite de telles chaînes comme des valeurs non correctes et signale des erreurs de conversion. Pour plus d'informations, consultez BULK INSERT (Transact-SQL).
Conversions datetime	Les conversions du type chaîne vers le type datetime sont marquées comme déterministes. Cependant, ceci n'est pas vrai pour les styles dont la liste figure dans le tableau suivant. Pour ces styles, les conversions dépendent des paramètres de langue. Le tableau suivant donne la liste des styles pour lesquels la conversion chaîne - datetime est non déterministe. Tous les styles inférieurs à 1001106 107109 113130

1 À l'exception des styles 20 et 21

SQL Server 2005 marque les conversions chaîne - datetime comme non déterministes.

DBCC CHECKFILEGROUP

Si un index non-cluster dans le groupe de fichiers spécifié est associé à une table dans un autre groupe de fichiers, l'index et la table de base sont vérifiés dans l'autre groupe de fichiers.

Si un index non-cluster dans le groupe de fichiers spécifié est associé à une table dans un autre groupe de fichiers, l'index n'est pas vérifié car la table de base n'est pas disponible pour être validée.

DBCC SHOW_STATISTICS

Le jeu de lignes renvoyé par DBCC SHOW_STATISTICS ne contient pas de colonne Name.

Le premier jeu de lignes renvoyé par DBCC SHOW_STATISTICS contient une colonne supplémentaire intitulée Name. Cette colonne apparaît comme la première colonne de l'ensemble de résultats. Si vous avez des applications qui accèdent aux colonnes renvoyées par DBCC SHOW_STATISTICS selon leur position ordinale, modifiez-les pour qu'elles accèdent aux colonnes par leur nom.

DROP LOGIN

Lorsque vous exécutez DROP LOGIN, la connexion n'est pas annulée si des utilisateurs sont mappés à cette connexion.

Lorsque vous exécutez DROP LOGIN, la connexion est annulée même si des utilisateurs de bases de données sont mappés à cette connexion.

Expressions dans des colonnes calculées, contraintes CHECK et contraintes DEFAULT

Le texte d'origine d'une expression, y compris les espaces, est préservé dans les métadonnées de catalogue. Par exemple, une expression de colonne calculée entrée sous la forme c1 + c2 + 1 apparaîtra exactement telle qu'elle a été entrée dans la colonne text de la table système syscomments.

Le texte d'origine d'une expression est décodé et normalisé, et le résultat de cette opération est stocké dans les métadonnées de catalogue. La sémantique de l'expression décodée sera équivalente au texte d'origine ; cependant, il n'existe aucune garantie syntaxique. Par exemple, une expression de colonne calculée qui est entrée sous la forme c1 + c2 + 1 apparaîtra sous la forme (([c1]+[c2])+(1)) dans la définition de colonne de l'affichage catalogue système sys.computed_columns.

Expressions dans les requêtes

Les expressions non sûres dans les requêtes ne génèrent pas toujours une exception à l'exécution.

SQL Server 2005 évalue parfois les expressions des requêtes plus tôt que SQL Server 2000 ne les évalue. Ce comportement offre de gros avantages :

Possibilité de faire correspondre les index sur des colonnes calculées aux expressions d'une requête qui sont identiques à l'expression de la colonne calculée.
Élimination des calculs redondants de résultats d'expressions.

Cependant, selon la nature de la requête et les données de la base de données, des exceptions à l'exécution peuvent se produire dans SQL Server 2005 si la requête contient une expression existante peu sûre. Ces exceptions à l'exécution sont les suivantes :

Exceptions arithmétiques : division par zéro, débordement et dépassement de précision.
Des échecs de conversion tels qu'une perte de précision et une tentative de convertir une chaîne non numérique en nombre
Agrégation sur un ensemble de valeurs qui ne sont pas toutes garanties différentes de la valeur NULL.

Il arrive que ces exceptions ne se produisent pas dans SQL Server 2000, dans une application spécifique utilisant des données spécifiques. Cependant, un plan de requêtes qui est modifié en raison de statistiques changeantes risque de provoquer une exception dans SQL Server 2000. Ces exceptions à l'exécution peuvent être évitées si vous modifiez la requête pour inclure des expressions conditionnelles telles que NULLIF ou CASE. Pour plus d'informations, consultez Dépannage des erreurs et des avertissements dans les expressions de requêtes.

fn_servershareddrives

Les données renvoyées par la fonction système fn_servershareddrives peuvent être affichées par les membres du rôle public.

Modification d'autorisation : fn_servershareddrives exige que l'utilisateur possède une autorisation VIEW SERVER STATE sur le serveur.

ms143359.note(fr-fr,SQL.90).gif Important :

Cette fonction système SQL Server 2000 est fournie pour des besoins de compatibilité descendante. Nous vous recommandons d'utiliser de préférence sys.dm_io_cluster_shared_drives.

fn_virtualfilestats

Les données renvoyées par la fonction système fn_virtualfilestats peuvent être affichées par les membres du rôle public.

Modification d'autorisation : fn_virtualfilestats exige que l'utilisateur possède une autorisation VIEW SERVER STATE sur le serveur.

fn_virtualservernodes

Les données renvoyées par la fonction système fn_virtualservernodes peuvent être affichées par les membres du rôle public.

Modification d'autorisation : fn_virtualservernodes exige que l'utilisateur possède une autorisation VIEW SERVER STATE sur le serveur.

ms143359.note(fr-fr,SQL.90).gif Important :

Cette fonction système SQL Server 2000 est fournie pour des besoins de compatibilité descendante. Nous vous recommandons d'utiliser de préférence sys.dm_os_cluster_nodes.

HOST_ID

HOST_ID renvoie une valeur char(8).

HOST_ID renvoie une valeur char(10).

Index

Les index décrits dans la colonne « Comportement de SQL Server 2005 » sont autorisés.

Il se peut que les index suivants soient désactivés durant le processus de mise à niveau ou nécessitent une reconstruction en raison de changements introduits dans SQL Server 2005.

Les index sur des colonnes calculées qui utilisent CHECKSUM(some_timestamp_column) seront désactivés parce que le comportement de la fonction Transact-SQL CHECKSUM a changé lorsqu'elle prend pour argument une colonne timestamp.
Les index contenant les valeurs de caractère 0x3390, 0x33ca ou 0x33cb dans des colonnes nvarchar ou nchar qui utilisent un classement basé sur la langue turque peuvent nécessiter une reconstruction car le comportement de tri de ces classements a changé.
Les index sur des colonnes calculées ou des vues dans lesquelles l'expression de vue ou de colonne calculée contient soit une conversion implicite de chaîne en datetime ou smalldatetime, soit une conversion explicite non déterministe de chaîne en datetime ou smalldatetime, seront désactivés.

Pour les index qui nécessitent une reconstruction en raison des changements décrits dans les deux premiers cas ci-dessus, utilisez la procédure suivante.

Examinez le journal d'erreurs de SQL Server à la recherche des messages d'avertissement 3801, 3803 ou 3804.
Exécutez DBCC CHECKTABLE sur la table sous-jacente pour vérifier s'il y a un problème.
Si les résultats de l'instruction DBCC révèlent l'existence d'un problème, reconstruisez l'index par l'une des méthodes suivantes :
- Instruction ALTER INDEX avec la clause REBUILD
- Instruction CREATE INDEX avec la clause DROP_EXISTING
- DBCC DBREINDEX
Identifiez les contraintes FOREIGN KEY désactivées à l'aide de l'instruction suivante :
```
SELECT * FROM sys.foreign_keys 
WHERE is_disabled=1;
```
Activez les éventuelles contraintes FOREIGN KEY à l'aide de l'instruction ALTER TABLE CHECK CONSTRAINT.
Les contraintes PRIMARY KEY et UNIQUE sont activées par la reconstruction de l'index associé. Vous devez reconstruire cet index pour pouvoir activer les contraintes FOREIGN KEY qui font référence à la contrainte PRIMARY KEY ou UNIQUE.

Pour les index désactivés en raison des changements décrits dans le troisième cas ci-dessus, utilisez la procédure suivante.

Identifiez les index sur les colonnes calculées qui ont été désactivés à l'aide de l'instruction suivante :

SELECT object_name(i.object_id) AS
 object_name, i.*
FROM sys.indexes AS i
JOIN sys.index_columns AS ic 
ON i.index_id = ic.index_id 
  AND i.object_id = ic.object_id
JOIN sys.computed_columns AS
 cc
ON ic.object_id = cc.object_id 
  AND ic.column_id = cc.column_id
WHERE i.is_disabled = 1

Pour un index de colonne calculée, supprimez l'index puis changez la définition de la colonne calculée pour qu'elle utilise une fonction CONVERT explicite avec un style de date déterministe.
Pour une vue indexée, supprimez la vue puis redéfinissez-la à l'aide d'une fonction CONVERT explicite avec un style de date déterministe.
Recréez l'index sur la colonne calculée ou la vue modifiée.

Index

Les opérations d'index parallèles sont prises en charge dans les éditions SQL Server 2000 Developer, SQL Server 2000 Standard et SQL Server 2000 Enterprise.

Les opérations d'index parallèles qui créent, suppriment ou reconstruisent des index ne sont disponibles que dans les éditions SQL Server 2005 Developer et SQL Server 2005 Enterprise.

Les utilisateurs qui effectuent une mise à niveau de SQL Server 2000 Standard Edition vers SQL Server 2005 Standard Edition doivent savoir que les opérations qui créent, suppriment ou reconstruisent des index sont exécutées en série dans SQL Server 2005 Standard Edition et peuvent durer plus longtemps.

Les instructions SELECT, INSERT, DELETE et UPDATE ne sont pas concernées. Elles s'exécutent en parallèle dans SQL Server 2005 Standard Edition.

Après avoir effectué une mise à niveau vers SQL Server 2005 Standard Edition, surveillez les opérations qui créent, suppriment ou reconstruisent les index. Vous devrez peut-être ajuster les scripts de maintenance ou les activités de maintenance planifiées pour allouer du temps supplémentaire à ces opérations.

Pour exécuter des opérations d'index parallèles, installez SQL Server 2005 Enterprise Edition.

Clause ORDER BY

Dans la clause ORDER BY, les noms de colonnes sont résolus vers les colonnes figurant dans la liste de sélection, qu'elles soient ou non qualifiées.

Par exemple, la requête suivante s'exécute sans erreur :

USE pubs
SELECT au_fname AS 'FName',
  au_lname AS 'LName'
FROM authors a
ORDER BY a.LName

SQL Server ignore le qualificateur a dans la clause ORDER BY et résout le nom de colonne LName vers la liste de sélection.

Les noms de colonnes et les alias qualifés sont résolus vers les colonnes des tables répertoriées dans la clause FROM. Si order_by_expression n'est pas qualifié, il doit être unique parmi toutes les colonnes répertoriées dans l'instruction SELECT.

Par exemple, la requête équivalente suivante renvoie une erreur :

USE AdventureWorks
SELECT FirstName AS 'FName',
    LastName AS 'LName'
FROM Person.Contact p
ORDER BY p.LName

SQL Server n'ignore pas le qualificateur p dans la clause ORDER BY et résout le nom de colonne LName vers les tables répertoriées dans la clause FROM. Mais la clause FROM ne reconnaît pas que la colonne LName est un alias de colonne de la table p.

Fonction SERVERPROPERTY

Le type de valeur renvoyée de la propriété ProductVersion de la fonction SERVERPROPERTY est varchar.

Le type de valeur renvoyée de la propriété ProductVersion de la fonction SERVERPROPERTY est nvarchar.

sp_addtype

Tout utilisateur peut exécuter sp_addtype.

Les utilisateurs doivent être membres du rôle de base de données db_ddladmin ou db_owner pour exécuter sp_addtype.

Pour permettre aux utilisateurs de créer des types de données alias, vous devez effectuer l'un des changements suivants :

Pour utiliser sp_addtype, ajoutez les utilisateurs au rôle de base de données db_ddladmin ou db_owner.
Pour créer un type de données alias à l'aide de CREATE TYPE, accordez une autorisation CREATE TYPE aux utilisateurs et une autorisation ALTER aux utilisateurs sur le schéma cible.

sp_altermessage

sp_altermessage peut être utilisé pour spécifier si un message système (un message avec Message ID < 50000) doit être écrit ou non dans le journal d'applications Windows.

sp_altermessage ne peut pas être utilisé pour modifier le comportement de journalisation des messages système (messages avec Message ID < 50000). Pour auditer les messages système, utilisez SQL Trace et la classe d'événements User Error Message. Pour plus d'informations, consultez Présentation de SQL Trace.

sp_changedbowner

Seuls les membres du rôle serveur fixe sysadmin, du rôle de base de données fixe db_owner, ou un membre des deux rôles de base de données fixe db_ddladmin et db_securityadmin peuvent exécuter sp_changeobjectowner.

Un utilisateur qui peut exécuter cette procédure stockée par son appartenance aux rôles de base de données fixe db_ddladmin et db_securityadmin doit aussi détenir une autorisation CONTROL sur le sécurisable. L'exécution de sp_changeobjectowner sans autorisation CONTROL sur l'objet cible échouera et déclenchera le message d'erreur suivant :

« Msg 15247, Niveau 16, État 1, Procédure sp_changeobjectowner, Ligne 17

L'utilisateur n'est pas autorisé à effectuer cette action. »

sp_help

sp_help renvoie un seul ensemble de résultats pour les fonctions.

sp_help renvoie deux jeux de résultats pour les fonctions. L'ensemble de résultats supplémentaire contient les paramètres des fonctions.

sysindexes

sys.sysindexes est fourni pour la compatibilité descendante. Cependant, des changements dans la version SQL Server 2005 empêche la vue d'être pleinement compatible avec les versions antérieures de SQL Server.

Métadonnées système

Les membres du rôle public peuvent interroger les tables système et afficher les métadonnées du catalogue.

Les utilisateurs qui interrogent le catalogue ne peuvent voir les lignes de métadonnées que pour les objets dont ils sont propriétaires ou sur lesquels ils ont une autorisation, ou sur lesquels ils ont une autorisation de consultation en raison de leur appartenance à un rôle. Pour plus d'informations et pour connaître les actions correctives recommandées, consultez Configuration de la visibilité des métadonnées et Dépannage de la visibilité des métadonnées.

Tables système

Les tables système sont de type 'S'.

Les tables système sont disponibles comme vues de compatibilité et sont de type 'V'. Les instructions qui interrogent les tables système et incluent les critères de recherche type = 'S' échouent.

Modifiez les critères de recherche de l'instruction en type = 'V'.

Migrez vers les nouveaux affichages catalogues ou les vues de gestion dynamiques. Pour plus d'informations, consultez Mappage des tables système SQL Server 2000 avec les vues du système SQL Server 2005.

TABLOCK lors de l'importation en bloc à l'aide de bcp, BULK INSERT ou OPENROWSET(BULK...)

Pour l'importation en bloc dans une table avec un index non-cluster non vide, l'indication TABLOCK est ignorée.

Pour l'importation en bloc dans une table avec un index cluster non vide, l'indication TABLOCK obtient un verrou X sur la table. Ce comportement empêche toute importation de données en bloc parallèle. Si vous souhaitez effectuer une importation parallèle en bloc, n'utilisez pas TABLOCK. Pour plus d'informations sur le chargement en bloc en parallèle, consultez Recommandations pour l'utilisation de l'importation en bloc.

Déclencheurs

La récurrence directe de déclencheurs se produit uniquement lorsqu'un déclencheur est activé et exécute une action qui l'active de nouveau.

La récurrence directe de déclencheurs se produit dans n'importe laquelle des circonstances suivantes :

Un déclencheur est activé et exécute une action qui l'active de nouveau.
Le même déclencheur est rappelé, mais ensuite, un déclencheur de type différent (AFTER ou INSTEAD OF) est appelé.

La récurrence indirecte se produit lorsqu'un déclencheur est activé et exécute une action qui active un autre déclencheur de même type (AFTER ou INSTEAD OF). Le deuxième déclencheur exécute une action qui active de nouveau le déclencheur de départ.

Pour plus d'informations, consultez la section « Déclencheurs récursifs » sous Déclencheurs imbriqués.

Déclencheurs

Lorsqu'une instruction UPDATE ou DELETE est émise par rapport à une vue partitionnée, locale ou distribuée, tout déclencheur UPDATE ou DELETE défini sur les tables de base de la vue est déclenché. Sont également inclus les déclencheurs non affectés par l'opération de mise à jour ou de suppression.

Lorsqu'une instruction UPDATE ou DELETE est émise par rapport à une vue partitionnée, un déclencheur UPDATE ou DELETE se déclenche uniquement si la table de base sur laquelle le déclencheur est défini est affectée par l'opération de mise à jour ou de suppression. Pour plus d'informations, consultez Exécution des déclencheurs DML.

Fonction UPDATE()

La fonction UPDATE() ne détecte pas les modifications des colonnes timestamp. Pour ces colonnes, une clause IF UPDATE() dans un corps de déclencheur renvoie FALSE, que les colonnes soient ou non mises à jour.

La fonction UPDATE() détecte les modifications des colonnes timestamp. Pour ces colonnes, une clause IF UPDATE() dans un corps de déclencheur DML renvoie TRUE si les colonnes sont mises à jour.

Fonctions définies par l'utilisateur

Les fonctions définies par l'utilisateur ne peuvent pas inclure de fonctions système intégrées non déterministes.

Les fonctions définies par l'utilisateur Transact-SQL peuvent inclure la plupart des fonctions système intégrées non déterministes. Pour obtenir la liste complète des fonctions intégrées autorisées, consultez Création de fonctions définies par l'utilisateur (moteur de base de données).

Types de données varchar, nvarchar et varbinary

Une chaîne nulle ou une valeur binaire utilisée en tant que définition d'une colonne de table calculée crée une colonne de type varchar(0), nvarchar(0) ou varbinary(0).

Une chaîne nulle ou une valeur binaire utilisée en tant que définition d'une colonne de table calculée crée une colonne de type varchar(1), nvarchar(1) ou varbinary(1). Cette modification de comportement affecte uniquement le type de données de la colonne calculée, mais pas la valeur calculée.

Modifiez les applications qui examinent la longueur des types de données de colonne calculée afin d'obtenir une longueur minimale d'1 octet pour les colonnes varchar et varbinary et de 2 octets pour les colonnes nvarchar.

Accès aux tables virtuelles

Les tables virtuelles sont accessibles aux invités ou aux membres du rôle public.

L'autorisation VIEW SERVER STATE et l'autorisation SELECT sont nécessaires pour accéder à une table virtuelle, telle que sysprocesses.

WITH CHECK OPTION sur les vues

Les opérations d'insertion et de mise à jour sont autorisées sur les vues qui spécifient la clause WITH CHECK OPTION et qui sont créées sur des tables distantes, même lorsque ces opérations ne se situent pas dans les limites de l'instruction SELECT de la vue.

SQL Server 2005 reconnaît la clause WITH CHECK OPTION lorsque les opérations d'insertion et de mise à jour sont effectuées sur des vues créées sur des tables à partir de sources de données distantes.

Si les opérations d'insertion et de mise à jour échouent sur des vues créées sur des tables distantes à cause de la clause WITH CHECK OPTION, et que vous ne souhaitez pas ce comportement, modifiez la vue en ne spécifiant pas la clause WITH CHECK OPTION.

Pour plus d'informations, consultez CREATE VIEW (Transact-SQL), ALTER VIEW (Transact-SQL) et Modification de données par l'intermédiaire d'une vue.

xp_cmdshell

Lorsqu'une erreur se produit dans l'exécution de xp_cmdshell, un message d'erreur est émis mais l'exécution n'est pas arrêtée.

Lorsqu'une erreur se produit dans l'exécution de xp_cmdshell, un message d'erreur est émis et l'exécution est arrêtée.

Voir aussi

Historique des modifications

Version	Historique
17 juillet 2006	Nouveau contenu Dans la table qui répertorie les changements de comportement de Transact-SQL, l'entrée « Expressions dans des colonnes calculées, contraintes CHECK et contraintes DEFAULT » a été ajoutée. Dans la table qui répertorie les changements de comportement de Transact-SQL, sous la colonne « Comportement de SQL Server 2005 », l'instruction pour l'entrée « Types de données varchar, nvarchar et varbinary » a été modifiée. Le type de données d'une colonne de table calculée est passé de nvarchar(2) à nvarchar(1).
5 décembre 2005	Nouveau contenu : Informations ajoutées sur les déclarations de curseurs qui ne sont pas valides. Contenu ajouté à « Modification de la langue par défaut d'un compte sa ». Contenu ajouté à « DBCC CHECKFILEGROUP ». Contenu ajouté à « TABLOCK lors de l'importation en bloc ». Contenu ajouté à « Déclencheurs ». Contenu modifié Contenu de « Types de données varchar, nvarchar et varbinary » corrigé.

17 juillet 2006

Nouveau contenu

Dans la table qui répertorie les changements de comportement de Transact-SQL, l'entrée « Expressions dans des colonnes calculées, contraintes CHECK et contraintes DEFAULT » a été ajoutée.
Dans la table qui répertorie les changements de comportement de Transact-SQL, sous la colonne « Comportement de SQL Server 2005 », l'instruction pour l'entrée « Types de données varchar, nvarchar et varbinary » a été modifiée. Le type de données d'une colonne de table calculée est passé de nvarchar(2) à nvarchar(1).

5 décembre 2005

Nouveau contenu :

Informations ajoutées sur les déclarations de curseurs qui ne sont pas valides.
Contenu ajouté à « Modification de la langue par défaut d'un compte sa ».
Contenu ajouté à « DBCC CHECKFILEGROUP ».
Contenu ajouté à « TABLOCK lors de l'importation en bloc ».
Contenu ajouté à « Déclencheurs ».

Contenu modifié

Contenu de « Types de données varchar, nvarchar et varbinary » corrigé.

Partager via