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

Article
12/15/2008

Mis à jour : 17 novembre 2008

Cette rubrique décrit les changements apportés au moteur de base de données dans Microsoft SQL Server 2005, qui risquent de provoquer le dysfonctionnement des applications basées sur des versions antérieures de SQL Server.

Connectivité client/serveur

Caractéristique	Description
Protocoles réseau Banyan VINES Sequenced Packet Protocol (SPP), Multiprotocol, AppleTalk ou NWLink IPX/SPX	SQL Server 2005 ne prend pas en charge les protocoles réseau Banyan VINES Sequenced Packet Protocol (SPP), Multiprotocol, AppleTalk et NWLink IPX/SPX Pour se connecter à SQL Server 2005, les applications clientes doivent utiliser un protocole pris en charge. Si un alias est défini, qui utilise l'un des protocoles non pris en charge, cet alias doit être modifié pour utiliser un protocole pris en charge. Si une chaîne de connexion d'application utilise ou charge de façon spécifique l'un des protocoles non pris en charge, en spécifiant soit NETWORK=DBMSRPCN pour RPC, soit NETWORK=DBMSADSN pour Appletalk, soit NETWORK=DBMSVINN pour la propriété Banyan VINES, ou en utilisant un préfixe explicite tel que spx:server\instance pour SPX, bv:server pour Banyan VINES, adsp:server pour AppleTalk ou rpc:server pour Multiprotocol, vous devez alors modifier votre application pour qu'elle utilise l'un des protocoles pris en charge. Pour plus d'informations, consultez Choix d'un protocole réseau.
MDAC	Les versions de MDAC antérieures à MDAC 2.6 ne prennent pas en charge les instances nommées. Pour permettre les connexions des applications aux instances nommées, effectuez la mise à niveau vers la version actuelle de MDAC.
Proxy Winsock	Le proxy Winsock ne peut pas être configuré avec les outils SQL Server. Pour des informations sur la configuration du proxy Winsock, consultez la documentation du serveur proxy.

Protocoles réseau Banyan VINES Sequenced Packet Protocol (SPP), Multiprotocol, AppleTalk ou NWLink IPX/SPX

SQL Server 2005 ne prend pas en charge les protocoles réseau Banyan VINES Sequenced Packet Protocol (SPP), Multiprotocol, AppleTalk et NWLink IPX/SPX Pour se connecter à SQL Server 2005, les applications clientes doivent utiliser un protocole pris en charge. Si un alias est défini, qui utilise l'un des protocoles non pris en charge, cet alias doit être modifié pour utiliser un protocole pris en charge.

Si une chaîne de connexion d'application utilise ou charge de façon spécifique l'un des protocoles non pris en charge, en spécifiant soit NETWORK=DBMSRPCN pour RPC, soit NETWORK=DBMSADSN pour Appletalk, soit NETWORK=DBMSVINN pour la propriété Banyan VINES, ou en utilisant un préfixe explicite tel que spx:server\instance pour SPX, bv:server pour Banyan VINES, adsp:server pour AppleTalk ou rpc:server pour Multiprotocol, vous devez alors modifier votre application pour qu'elle utilise l'un des protocoles pris en charge.

Pour plus d'informations, consultez Choix d'un protocole réseau.

MDAC

Les versions de MDAC antérieures à MDAC 2.6 ne prennent pas en charge les instances nommées. Pour permettre les connexions des applications aux instances nommées, effectuez la mise à niveau vers la version actuelle de MDAC.

Proxy Winsock

Le proxy Winsock ne peut pas être configuré avec les outils SQL Server. Pour des informations sur la configuration du proxy Winsock, consultez la documentation du serveur proxy.

Options de configuration

Caractéristique

Description

AUTO_UPDATE_STATISTICS

Définissez AUTO_UPDATE_STATISTICS sur ON avant de mettre à niveau une base de données, quelle qu'elle soit. Sinon, les statistiques de base de données ne sont pas mises à jour dans le cadre de la mise à niveau vers SQL Server 2005. L'utilisation de statistiques remontant à une ancienne version de SQL Server risque d'aboutir à des plans de requête sous-optimisés. Si vous définissez AUTO_UPDATE_STATISTICS sur ON, toutes les statistiques sont mises à jour dès leur premier référencement. La mise à jour des statistiques accroît la possibilité que des plans de requête mieux optimisés soient sélectionnés lorsque vous exécutez des requêtes.

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

Dans certains cas, après avoir défini AUTO_UPDATE_STATISTICS sur ON, le processus de mise à jour des statistiques peut influencer l'exécution de requêtes sur le serveur lors du premier référencement des statistiques.

Pour définir l'option SET de base de données AUTO_UPDATE_STATISTICS sur ON, utilisez l'instruction ALTER DATABASE ; ou bien, pour actualiser les statistiques dans la base de données, exécutez sp_updatestats.

Option max server memory

Dans SQL Server 2000, le pool de tampons SQL Server peut dépasser la limite spécifiée par l'option max server memory si la mémoire physique du système est disponible. Dans SQL Server 2005, le pool de tampons ne peut pas dépasser la valeur de max server memory. Lorsque cette limite est atteinte, la requête échoue avec un message d'erreur « mémoire système insuffisante ».

Si vous recevez ce message d'erreur alors que l'option max server memory est définie, augmentez la valeur de cette option ou restaurez sa valeur par défaut, 2147483647. Pour plus d'informations, consultez Options de mémoire du serveur.

Option query governor cost limit

L'application de SET GOVERNOR_QUERY_COST_LIMIT ou de l'option query governor cost limit de sp_configure peut aboutir à ce que les requêtes s'exécutant dans une version antérieure de SQL Server ne fonctionnent plus dans SQL Server 2005. Ce comportement est dû à des changements dans le modèle de coût des requêtes.

Modifiez les paramètres de limite de coût de l'Administrateur de requêtes de la connexion ou de l'instance de serveur à une valeur appropriée, ou définissez la valeur 0 pour spécifier que la durée d'exécution d'une requête n'est pas limitée.

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

Caractéristique	Description
Unités compressées	SQL Server 2005 ne peut pas créer ou mettre à niveau des bases de données sur des unités compressées. Lorsque vous installez SQL Server 2005, sélectionnez une unité non compressée pour les bases de données système et vérifiez que les bases de données à mettre à niveau ne sont pas situées sur des unités compressées. Sachez cependant qu'après mise à niveau de la base de données, vous pouvez placer les bases de données en lecture seule et les groupes de fichiers secondaires en lecture seule sur un système de fichiers compressés NTFS.
Fichiers de données	Un espace disque supplémentaire est nécessaire aux fichiers de données pour tenir compte des changements suivants : Des métadonnées système supplémentaires sont créées et conservées dans le groupe de fichiers PRIMARY de chaque base de données utilisateur pour les objets de base de données et les autorisations d'utilisateurs. Par exemple, dans les versions précédentes de SQL Server, les autorisations associées à un fournisseur ou un bénéficiaire d'autorisations étaient stockées sur une seule ligne sous forme de bitmap. Dans SQL Server 2005, le bitmap s'étend sur plusieurs lignes. Chaque colonne LOB (large object) définie dans les types de données text, ntext ou image a besoin de 40 octets d'espace disque supplémentaire. Cette expansion ne se produit qu'une fois, durant la première mise à jour de chaque colonne LOB. Le mappage des ID de documents (DOCID) de texte intégral est stocké dans le fichier de données et non pas dans le catalogue de texte intégral. Pour vous assurer que les ressources pourront gérer les accroissements de taille durant la mise à niveau et les opérations ultérieures de production, nous vous recommandons d'activer la croissance automatique (sur ON) pour tous les fichiers de données d'utilisateurs, avant la mise à niveau vers SQL Server 2005. Après la mise à niveau, et après avoir testé vos charges de travail, vous pouvez redéfinir la croissance automatique sur OFF ou ajuster l'incrément FILEGROWTH. Pour plus d'informations, consultez ALTER DATABASE (Transact-SQL).
Mode Compatibilité de la base de données	Lorsqu'une base de données est mise à niveau vers SQL Server 2005 à partir d'une version antérieure de SQL Server, la base de données conserve son niveau de compatibilité existant. Si après la mise à niveau, vous changez le mode de compatibilité à 90, les différences de modes de compatibilité risquent d'avoir des conséquences sur vos applications. Pour plus d'informations sur ces différences, consultez sp_dbcmptlevel (Transact-SQL).
ID de base de données 32767	Dans SQL Server 2005, cet ID de base de données est réservé. Détachez la base de données avant la mise à niveau.
Groupes de fichiers	Toutes les bases de données de l'instance de SQL Server doivent avoir leurs groupes de fichiers définis sur READ_WRITE avant la mise à niveau vers SQL Server 2005. Pour définir un groupe de niveau sur READ_WRITE, utilisez ALTER DATABASE.
Fichiers journaux	Dans SQL Server 2005, un espace disque supplémentaire est nécessaire pour les fichiers journaux de transactions. Durant la phase de restauration d'une récupération après panne, SQL Server 2005 permet aux utilisateurs d'accéder à la base de données. Cela est possible parce que les transactions qui n'étaient pas validées lorsque l'incident s'est produit retrouvent les verrous dont elles disposaient avant l'incident. Lors de la restauration des transactions, leurs verrous les protègent de toute interférence avec les utilisateurs. Ces informations de verrouillage complémentaires doivent être conservées dans le journal des transactions. Pour vous assurer que les ressources pourront gérer les accroissements de taille durant la mise à niveau et les opérations de productions ultérieures, nous vous recommandons d'activer la croissance automatique (sur ON) pour tous les fichiers journaux d'utilisateurs avant votre mise à niveau vers SQL Server 2005. Après la mise à niveau, et après avoir testé vos charges de travail, vous pouvez redéfinir la croissance automatique sur OFF ou ajuster l'incrément FILEGROWTH. Pour plus d'informations, consultez ALTER DATABASE (Transact-SQL).
Base de données model	Dans SQL Server 2005, la base de données model contient les changements suivants : Taille minimale plus importante. Niveau de compatibilité défini à 90. Option de base de données PAGE_VERIFY définie à CHECKSUM.
Base de données tempdb	Un espace disque supplémentaire est nécessaire pour les fichiers de données tempdb et les fichiers journaux dans SQL Server 2005. Pour vous assurer que les ressources pourront gérer les accroissements de taille durant la mise à niveau et les opérations ultérieures de production, nous vous recommandons d'activer la croissance automatique (sur ON) pour tous les fichiers de données tempdb et les fichiers journaux avant votre mise à niveau vers SQL Server 2005. Après la mise à niveau, et après avoir testé vos charges de travail, vous pouvez redéfinir la croissance automatique sur OFF ou ajuster l'incrément FILEGROWTH. Pour plus d'informations, consultez Résolution des problèmes d'espace disque insuffisant dans tempdb.

Fonctionnalités

Caractéristique

Description

Procédures stockées étendues

Les procédures stockées étendues déjà enregistrées sans le chemin d'accès complet pour le nom DLL risquent de ne pas fonctionner après la mise à niveau vers SQL Server 2005. Ceci est dû à ce que l'ancien répertoire BINN n'est pas ajouté au nouveau chemin durant le processus de mise à niveau. SQL Server risque de ne pas pouvoir localiser les procédures stockées étendues.

Avant de lancer la mise à niveau vers SQL Server 2005, effectuez les étapes suivantes pour chaque procédure stockée étendue qui n'est pas enregistrée à l'aide d'un nom de chemin complet :

Pour supprimer la procédure stockée étendue, exécutez sp_dropextendedproc.
Pour enregistrer la procédure stockée étendue avec le nom de chemin complet, exécutez sp_addextendedproc.

Copie des journaux de transaction

La copie des journaux de transaction dans les anciennes versions de SQL Server n'est pas compatible avec la copie des journaux de transaction de SQL Server 2005, et ne peut pas être mis à niveau directement. Après avoir mis à niveau vers SQL Server 2005, reconfigurez la copie des journaux de transaction à l'aide de SQL Server Management Studio ou de procédures stockées. Pour plus d'informations, consultez Migration d'une configuration de la copie des journaux de transaction vers SQL Server 2005.

Utilitaire osql

L'utilitaire osql ne prend pas en charge les commandes ED et !!. Supprimez de vos scripts les références aux commandes ED et !!. Pour utiliser les commandes ED et !!, servez-vous plutôt de l'utilitaire sqlcmd.

Fournisseur WMI SQL-DMO

Le fournisseur WMI SQL-DMO a été abandonné et n'est plus disponible.

SQL Mail

SQL Server prend en charge la mise à niveau de SQL Mail à partir de SQL Server 7.0 ou SQL Server 2000 ; cependant, SQL Server 2005 nécessite Microsoft Outlook 2002 ou une version ultérieure comme client de messagerie.

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

Cette fonctionnalité sera supprimée dans une prochaine version de Microsoft SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement, et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité. Pour envoyer du courrier à partir de SQL Server 2005, utilisez la messagerie de base de données.

SQL Mail

Lorsqu'un client connecté à l'aide de l'authentification SQL Server tente d'envoyer un message SQL Mail contenant une pièce jointe, SQL Server n'est pas en mesure de définir un contexte de sécurité approprié et renvoie une erreur. Pour éviter ce problème, utilisez l'authentification Windows.

API SQL Namespace (SQL-NS)

L'API SQL Namespace (SQL-NS) a été abandonnée et n'est plus disponible.

Indicateurs de trace

Dans SQL Server 2000, un indicateur de trace défini dans la session A ne prend pas automatiquement effet dans une session B déjà existante. Il prend effet uniquement après qu'un premier indicateur de trace a été défini dans la session B. Ce comportement est non déterministe dans SQL Server 2000, et déterministe dans SQL Server 2005. Dans SQL Server 2005, les indicateurs de trace globaux définis dans la session A sont immédiatement définis dans les autres sessions simultanées.

En outre, dans SQL Server 2005, les indicateurs de trace peuvent être spécifiés soit comme locaux, soit comme globaux, à l'aide d'un argument supplémentaire dans l'instruction DBCC TRACEON. Si le deuxième argument n'est pas spécifié, la valeur par défaut est locale dans SQL Server 2005. Ceci diffère de SQL Server 2000, dans lequel la valeur par défaut est globale.

Pour plus d'informations, consultez Indicateurs de trace (Transact-SQL).

Indicateurs de trace

Certains indicateurs de trace SQL Server 2000 n'existent plus dans SQL Server 2005. En outre, certains indicateurs de trace ont une fonctionnalité différente dans SQL Server 2005. Veillez à désactiver tous les indicateurs de trace avant une mise à niveau vers SQL Server 2005. Après la mise à niveau, vérifiez que la fonctionnalité de l'indicateur de trace n'a pas changé. Assurez-vous aussi que l'indicateur de trace est encore nécessaire avant de le réactiver.

Déclencheurs

Dans SQL Server 2005, les instructions du langage de définition de données (DDL), telles que CREATE INDEX, ne peuvent pas être exécutées sur les tables insérées et supprimées dans les déclencheurs DML. Dans les versions antérieures de SQL Server, certaines instructions DDL pouvaient être exécutées sur les tables insérées et supprimées. Pour plus d'informations, consultez Utilisation des tables inserted et deleted.

Noms d'index en double

Dans SQL Server 2005, les noms d'index de table ou de vue en double ne sont pas autorisés. Renommez les index pour supprimer les doublons avant la mise à niveau.

Pour repérer les index en double, exécutez la requête suivante :

SELECT DISTINCT OBJECT_NAME(o.id), name
FROM sysindexes as o
WHERE EXISTS 
    (SELECT name FROM sysindexes  as i
      WHERE i.id = o.id
      AND i.name = o.name and i.indid < o.indid);

Utilisez sp_rename pour changer l'un des noms d'index. Ces noms étant identiques, vous ne pouvez pas déterminer quel index sera renommé. La procédure qui suit vous permet de différencier les deux index.
```
EXEC sp_rename N'table_name.index_name', N'new_index_name, N'INDEX'
```

Pour vérifier quel index a été renommé, exécutez la requête suivante. Elle renvoie tous les index, y compris les noms des colonnes clés de la table ou de la vue spécifiée :

SELECT i.name AS IndexName, c.name AS ColumnName, ik.colid, ik.keyno
FROM sysindexes i
JOIN sysindexkeys ik ON i.id = ik.id and i.indid = ik.indid 
JOIN syscolumns c ON c.id = ik.id and ik.colid = c.colid
WHERE i.id = OBJECT_ID('table_or_view_name')

Si nécessaire, utilisez de nouveau sp_rename pour corriger les noms d'index.

Noms d'objets

Dans SQL Server 2005, vous ne pouvez pas utiliser la caractère 0xFFFF dans les noms d'objets. Un nom d'objet contenant ce caractère Unicode n'est pas accessible lorsque la base de données se situe dans le niveau de compatibilité 90. Renommez les objets qui contiennent ce caractère.

Correspondance entre les variables de table et le classement de colonne

Dans SQL Server 2000, les colonnes définies dans des variables de table sont converties implicitement au classement de la base de données tempdb. Dans SQL Server 2005, les colonnes définies dans des variables de table sont converties implicitement au classement de la base de données active. Les requêtes qui reposent sur le comportement de SQL Server 2000 peuvent retourner des résultats inattendus, tels qu'une quantité ou un ordre de lignes retournées différent.

Par exemple, la comparaison d'égalité des colonnes c1 et c2 dans la clause WHERE de l'instruction SELECT suivante peut retourner plus ou moins de lignes lorsque le classement de la base de données TestDB est utilisé à la place du classement de tempdb. Par exemple, les valeurs 'Nom' et 'nom' sont évaluées comme étant égales lorsque le classement respecte la casse, mais pas dans le cas contraire.

CREATE DATABASE TestDB COLLATE Estonian_CS_AI;
GO
USE TestDB;
DECLARE @TempTable table (c1 varchar(10), c2 varchar(10);
SELECT * FROM @TempTable WHERE c1 = c2;

Pour utiliser un classement autre que le classement de la base de données active dans une variable de table, spécifiez le classement dans la définition des colonnes dans l'instruction DECLARE ou dans la requête qui fait référence aux colonnes. L'exemple suivant illustre les deux méthodes.

USE TestDB;
DECLARE @TempTable table (c1 varchar(10)COLLATE Latin1_General_CS_AS, c2 varchar(10)COLLATE Latin1_General_CS_AS);
SELECT * FROM @TempTable WHERE c1 = c2;
GO
-- or

DECLARE @TempTable table (c1 varchar(10), c2 varchar(10));
SELECT * FROM @TempTable WHERE c1 = c2 COLLATE Latin1_General_CS_AS;
GO

Vues indexées

Caractéristique Description

Caractéristique	Description
Déterminisme des fonctions	Les expressions de fonctions suivantes sont considérées comme non déterministes dans SQL Server 2005, et par conséquent elles peuvent interférer avec la création de vues indexées : Références à des littéraux de chaîne qui sont implicitement convertis en datetime et smalldatetime. Conversion implicite des données en caractères non Unicode entre les classements. Les expressions entraînant la conversion implicite de chaînes de caractères en datetime ou smalldatetime sont considérées comme non déterministes dans SQL Server 2005, sauf si le niveau de compatibilité est égal ou inférieur à 80. En effet, les résultats dépendent des paramètres LANGUAGE ou DATEFORMAT de la session de serveur. Par exemple, les résultats de l'expression `CONVERT (datetime, '30 listopad 1996', 113)` dépendent du paramètre LANGUAGE, parce que la chaîne '`listopad`' représente différents mois dans différentes langues. De même, dans l'expression `DATEADD(mm,3,'2000-12-01')`, SQL Server interprète la chaîne `'2000-12-01'` en fonction du paramètre DATEFORMAT. La conversion implicite de données de caractères non-Unicode entre les classements est également considérée comme non déterministe, à moins que le niveau de compatibilité ne soit réglé sur 80 ou antérieur. La création d'index sur des vues contenant ces expressions n'est pas autorisée au niveau de compatibilité de base de données 90. Bien qu'il soit possible de conserver les vues existantes qui contiennent ces expressions, en provenance d'une base de données mise à niveau, l'optimiseur de requêtes ne les prend pas en considération dans les plans de requête aux niveaux de compatibilité 80 et 90. Pour plus d'informations sur la définition du niveau de compatibilité, consultez sp_dbcmptlevel (Transact-SQL). Dans la définition de vues indexées dans SQL Server 2005, vous devez convertir explicitement le littéral dans le type de données voulu, en utilisant un style de format de date déterministe. Pour obtenir la liste des styles de formats de date déterministes, consultez CAST et CONVERT (Transact-SQL). Si vous utilisez des conversions implicites de chaînes en dates dans des vues indexées existantes ayant été mises à niveau vers SQL Server 2005, assurez-vous que les paramètres LANGUAGE et DATEFORMAT sont cohérents dans vos bases de données et vos applications, pour éviter une possible corruption des vues indexées.
IGNORE_DUP_KEY	Quand vous créez un index cluster unique sur une vue dans SQL Server 2005, l'option IGNORE_DUP_KEY doit être définie sur OFF. Il s'agit du paramètre par défaut. Si elle était définie sur ON, les vues indexées pourraient être corrompues. Supprimez l'index cluster sur la vue et créez-le de nouveau sans spécifier l'option IGNORE_DUP_KEY.
Indicateurs de requête	Les indicateurs de requêtes dans les définitions des vues indexées sont ignorés au niveau de compatibilité 80. Cela peut provoquer un comportement différent des applications entre le niveau de compatibilité 80 et le niveau 90. Pour plus d'informations, consultez Conception des vues indexées, Création de vues indexées et Indicateur de requête (Transact-SQL).

Déterminisme des fonctions

Les expressions de fonctions suivantes sont considérées comme non déterministes dans SQL Server 2005, et par conséquent elles peuvent interférer avec la création de vues indexées :

Références à des littéraux de chaîne qui sont implicitement convertis en datetime et smalldatetime.
Conversion implicite des données en caractères non Unicode entre les classements.

Les expressions entraînant la conversion implicite de chaînes de caractères en datetime ou smalldatetime sont considérées comme non déterministes dans SQL Server 2005, sauf si le niveau de compatibilité est égal ou inférieur à 80. En effet, les résultats dépendent des paramètres LANGUAGE ou DATEFORMAT de la session de serveur. Par exemple, les résultats de l'expression CONVERT (datetime, '30 listopad 1996', 113) dépendent du paramètre LANGUAGE, parce que la chaîne 'listopad' représente différents mois dans différentes langues. De même, dans l'expression DATEADD(mm,3,'2000-12-01'), SQL Server interprète la chaîne '2000-12-01' en fonction du paramètre DATEFORMAT.

La conversion implicite de données de caractères non-Unicode entre les classements est également considérée comme non déterministe, à moins que le niveau de compatibilité ne soit réglé sur 80 ou antérieur.

La création d'index sur des vues contenant ces expressions n'est pas autorisée au niveau de compatibilité de base de données 90. Bien qu'il soit possible de conserver les vues existantes qui contiennent ces expressions, en provenance d'une base de données mise à niveau, l'optimiseur de requêtes ne les prend pas en considération dans les plans de requête aux niveaux de compatibilité 80 et 90. Pour plus d'informations sur la définition du niveau de compatibilité, consultez sp_dbcmptlevel (Transact-SQL).

Dans la définition de vues indexées dans SQL Server 2005, vous devez convertir explicitement le littéral dans le type de données voulu, en utilisant un style de format de date déterministe. Pour obtenir la liste des styles de formats de date déterministes, consultez CAST et CONVERT (Transact-SQL).

Si vous utilisez des conversions implicites de chaînes en dates dans des vues indexées existantes ayant été mises à niveau vers SQL Server 2005, assurez-vous que les paramètres LANGUAGE et DATEFORMAT sont cohérents dans vos bases de données et vos applications, pour éviter une possible corruption des vues indexées.

IGNORE_DUP_KEY

Quand vous créez un index cluster unique sur une vue dans SQL Server 2005, l'option IGNORE_DUP_KEY doit être définie sur OFF. Il s'agit du paramètre par défaut. Si elle était définie sur ON, les vues indexées pourraient être corrompues.

Supprimez l'index cluster sur la vue et créez-le de nouveau sans spécifier l'option IGNORE_DUP_KEY.

Indicateurs de requête

Les indicateurs de requêtes dans les définitions des vues indexées sont ignorés au niveau de compatibilité 80. Cela peut provoquer un comportement différent des applications entre le niveau de compatibilité 80 et le niveau 90. Pour plus d'informations, consultez Conception des vues indexées, Création de vues indexées et Indicateur de requête (Transact-SQL).

Sécurité

Caractéristique	Description
Noms de connexion	Les noms de rôles serveur fixe suivants sont réservés dans SQL Server 2005 et ne peuvent pas être utilisés comme noms de connexion définis par l'utilisateur : sysadmin serveradmin setupadmin securityadmin processadmin dbcreator diskadmin bulkadmin Avant une mise à niveau vers SQL Server 2005, procédez comme suit : Prenez note des SID (identificateurs de sécurité) des connexions en exécutant l'instruction suivante : `SELECT name, sid FROM master.dbo.syslogins WHERE name IN('sysadmin', 'serveradmin','setupadmin', 'securityadmin','processadmin', 'dbcreator','diskadmin', 'bulkadmin')` Supprimez les connexions. Pour créer de nouvelles connexions, utilisez la procédure système sp_addlogin. Dans le paramètre @sid de chaque connexion correspondante, spécifiez le SID renvoyé à l'étape 1.
Identificateur de sécurité (SID) de la connexion	Dans SQL Server 2005, les identificateurs de sécurité (SID) en double ne sont pas autorisés. Supprimez l'une des connexions et les utilisateurs associés avant la mise à niveau.
Mappage de connexion d'accès distant	Dans les versions précédentes de SQL Server, les connexions en provenance d'instances distantes de SQL Server peuvent être marquées comme approuvées à l'aide de la procédure stockée système sp_remoteoption. SQL Server 2005 ne prend pas en charge cette méthode d'étiquetage des connexions distantes. Après la mise à niveau vers SQL Server 2005, les connexions distantes ne seront plus marquées comme approuvées. Pour configurer et gérer les connexions distantes, utilisez des serveurs liés et des procédures stockées de serveurs liés. Pour plus d'informations, consultez Liaison des serveurs.
Connexions SQL Server 6.5	SQL Server 6.5 enregistre les hachages de mots de passe sous un format qui n'est plus pris en charge. L'ancien mot de passe ne peut plus être directement mis à niveau vers SQL Server 2005. Pour activer cette connexion, vous devez redéfinir le mot de passe. Pour redéfinir le mot de passe, vous pouvez utiliser ALTER LOGIN : `ALTER LOGIN <login name> WITH PASSWORD = '<new password>' MUST_CHANGE` Le nouveau mot de passe sera validé par rapport à la stratégie de complexité des mots de passe de votre système, sauf si la vérification de stratégie est désactivée. Nous vous recommandons d'utiliser des mots de passe complexes et de ne pas désactiver la vérification de stratégie. L'option MUST_CHANGE oblige l'utilisateur à choisir un nouveau mot de passe. Cette étape est recommandée, mais elle n'est pas obligatoire. Vous pouvez identifier les connexions SQL Server 6.5 dormantes à l'aide de la requête suivante : `SELECT * FROM sysxlogins WHERE (xstatus & 2048) = 2048; GO`
Nom d'utilisateur sys	Le nom sys est réservé dans SQL Server 2005 et ne peut pas être choisi comme nom d'utilisateur. Renommez l'utilisateur avant la mise à niveau vers SQL Server 2005. Si l'utilisateur n'est pas renommé, la base de données sera en état suspect après le processus de mise à niveau et ne sera pas disponible tant qu'elle n'aura pas été mise en ligne. Procédure avant mise à niveau Avant la mise à niveau vers SQL Server 2005, dans chaque base de données contenant l'utilisateur sys, effectuez les actions suivantes : Créez un nouvel utilisateur. Utilisez les instructions suivantes pour afficher toutes les autorisations accordées par l'utilisateur sys et accordées à l'utilisateur sys. `-- Return permissions granted by user sys. SELECT * FROM sysprotects WHERE grantor = USER_ID('sys') -- Return permissions granted to user sys. SELECT * FROM sysprotects WHERE uid = USER_ID('sys')` Pour transférer l'appartenance de tous les objets possédés par sys au nouvel utilisateur, utilisez sp_changeobjectowner. Supprimez l'utilisateur sys. Pour restaurer les autorisations d'origine capturées à l'étape 2, utilisez la clause AS new_user de l'instruction GRANT. Modifiez les scripts pour qu'ils fassent référence au nouvel utilisateur. Procédure après mise à niveau Si l'utilisateur sys n'a pas été renommé avant la mise à niveau, procédez ainsi : Exécutez l'instruction `ALTER DATABASE db_name SET ONLINE`. La base de données se trouvera en mode SINGLE_USER. Suivez toute la procédure de la section « Procédure avant mise à niveau ». Exécutez l'instruction `ALTER DATABASE db_name SET MULTI_USER`.

Objets et métadonnées système

Caractéristique	Description
INFORMATION_SCHEMA.COLUMNS	Dans SQL Server 2005, la colonne ORDINAL_POSITION de la vue INFORMATION_SCHEMA.COLUMNS n'est pas compatible avec la série de bits renvoyée par la fonction COLUMNS_UPDATED. Pour obtenir une série de bits compatible avec COLUMNS_UPDATED, référencez la propriété ColumnID de la fonction système COLUMNPROPERTY lorsque vous interrogez la vue INFORMATION_SCHEMA.COLUMNS, comme dans l'exemple suivant : `SELECT TABLE_NAME, COLUMN_NAME, COLUMNPROPERTY(OBJECT_ID(TABLE_SCHEMA + '.' + TABLE_NAME), COLUMN_NAME, 'ColumnID') AS COLUMN_ID FROM AdventureWorks.INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'Contact';`
INFORMATION_SCHEMA.SCHEMATA	Dans les versions antérieures de SQL Server, la vue INFORMATION_SCHEMA.SCHEMATA renvoyait toutes les bases de données existant dans une instance de SQL Server. Dans SQL Server 2005, cette vue renvoie tous les schémas d'une base de données. Ce comportement est conforme à SQL standard. Pour plus d'informations, consultez SCHEMATA (Transact-SQL).
Noms de colonnes INFORMATION_SCHEMA correspondant à la valeur '%SCHEMA'	Dans les versions précédentes de SQL Server, les noms de colonnes INFORMATION_SCHEMA qui correspondent à la valeur '%SCHEMA' renvoient le nom de l'utilisateur. Dans SQL Server 2005, ces colonnes renvoient le nom du schéma. Lors de la mise à niveau d'une base de données vers SQL Server 2005, le nom de schéma est toujours identique au nom de l'utilisateur et les applications qui font référence à ces colonnes n'échoueront pas. Cependant, les utilisateurs qui implémentent les fonctions de séparation utilisateur-schéma de SQL Server 2005 dans leurs bases de données doivent savoir que leur application risque d'échouer si la donnée attendue est un nom d'utilisateur et non pas un nom de schéma. Pour plus d'informations, consultez Séparation du schéma et de l'utilisateur.
sp_helptrigger	SQL Server 2005 ajoute trigger_schema comme dernière colonne dans le jeu de résultats renvoyé par la procédure stockée système sp_helptrigger. Vérifiez l'emploi de sp_helptrigger dans vos applications. Vous devrez peut-être modifier vos applications pour tenir compte de cette colonne supplémentaire. Vous pouvez également utiliser l'affichage catalogue sys.triggers.
syslockinfo et sp_lock	Dans SQL Server 2000, les colonnes rsc_objid rsc_indid dans syslockinfo et les colonnes objid et indid dans sp_lock renvoient toujours l'ID d'objet et l'ID d'index. Dans SQL Server 2005, la valeur 0 peut être renvoyée. Dans SQL Server 2000, syslockinfo et sp_lock renvoient un maximum de deux lignes pour toute ressource de verrou spécifique dans une même transaction. Dans SQL Server 2005, lorsque le partitionnement de verrous est activé, plusieurs lignes peuvent être renvoyées pour la même ressource s'exécutant sous une transaction. Le nombre de lignes renvoyées peut être de N + 1, où N représente le nombre de processeurs. En outre, dans SQL Server 2005, les requêtes GRANTED et WAITING peuvent être affichées pour la même ressource ; dans SQL Server 2000, ces requêtes ne peuvent pas être affichées pour la même ressource. Pour plus d'informations, consultez sp_lock (Transact-SQL) et sys.syslockinfo (Transact-SQL).
Mise en correspondance du classement des noms d'objets système et des noms de types système	Dans les versions antérieures de SQL Server, les noms d'objets système et de types système étaient alignés sur le classement de la base de données master. Dans SQL Server 2005, les noms d'objets système et de types système sont convertis automatiquement pour correspondre au classement de la base de données active. Si les références à ces objets dans vos scripts ou applications ne correspondent pas à leur apparence dans le catalogue et si la base de données active contient un classement respectant la casse, le script ou l'application risque d'échouer. Par exemple, l'instruction `EXEC SP`_`heLP` échoue si la base de données active a un classement qui respecte la casse.
Modification d'un objet système	Les mises à jour directes de catalogues système ne sont pas autorisées dans SQL Server 2005. Toute tentative à cet égard génère l'erreur suivante : « Serveur : Msg 259, Niveau 16, État 1, Ligne 1 » « Les mises à jour appropriées des catalogues du système ne sont pas autorisées. » Modifiez vos scripts SQL pour qu'ils utilisent des API officielles et documentées. Par exemple, utilisez ALTER DATABASE database_name SET EMERGENCY plutôt que d'exécuter une instruction UPDATE sur la table système sysdatabases.
Suppression d'un objet système	Les instructions telles que DROP TABLE, DROP PROCEDURE et sp_dropextendedproc ne peuvent pas servir à supprimer des objets système, car ces objets sont déployés dans la Base de données des ressources en lecture seule. Supprimez toutes les instructions qui tentent d'éliminer des objets système de votre application. Modifiez vos applications pour qu'elles révoquent ou qu'elles refusent les autorisations EXECUTE sur les objets système. D'une autre manière, vous pouvez utiliser l'un des outils Configuration de la surface d'exposition de SQL Server 2005 pour désactiver certains de ces objets. Par exemple, la procédure stockée étendue xp_cmdshell peut être désactivée ou activée à l'aide de l'un des outils Configuration de la surface d'exposition.
sysperfinfo	Dans SQL Server 2005, sysperfinfo renvoie une valeur bigint pour la colonne cntr_value. Modifiez les applications qui utilisent sysperfinfo pour vous assurer qu'elles peuvent traiter les valeurs bigint de la colonne cntr_value. Dans SQL Server 2005, sysperfinfo est une vue de compatibilité. Utilisez de préférence la vue de gestion dynamique sys.dm_os_performance_counters.
Tables système interrogées avec 'dbo' dans les critères de recherche.	Dans les versions précédentes de SQL Server, les objets système sont détenus par dbo et résident dans la base de données master. Dans SQL Server 2005, les objets système sont détenus par sys et apparaissent logiquement dans chaque base de données. Les instructions qui interrogent les tables système et possèdent des critères de recherche spécifiant l'utilisateur dbo échouent.

Transact-SQL

Caractéristique	Description
@@VERSION	SQL Server 2005 renvoie des informations plus détaillées que SQL Server 2000, sous le format major.minor.build.incremental-build.
CREATE STATISTICS	La spécification de WITH ROWS dans les instructions CREATE STATISTICS n'est pas prise en charge dans SQL Server 2005. Modifiez les instructions CREATE STATISTICS contenant WITH ROWS en spécifiant SAMPLE number entre WITH et ROWS, ou en spécifiant d'autres options compatibles avec la syntaxe documentée.
DISK INIT	L'instruction DISK INIT, utilisée dans les versions précédentes de SQL Server pour créer des unités de bases de données ou de journaux de transactions, a été supprimée dans SQL Server 2005. Remplacez toutes les occurrences de cette instruction par les instructions équivalentes CREATE DATABASE ou ALTER DATABASE.
UNION dans une instruction INSERT INTO...SELECT	Lorsqu'un opérateur UNION est placé dans une instruction INSERT, SQL Server 2005 convertit séparément le type de données de chaque opération UNION en fonction des règles de conversion des types de données. Puis, les types de données du résultat final de l'opération UNION sont convertis vers les colonnes correspondantes de la table ciblée par l'opération INSERT. Ce changement de comportement peut provoquer des erreurs de conversion de types de données dans vos applications. L'exemple suivant illustre une erreur de conversion de type de données. Dans les niveaux de compatibilité inférieurs ou égaux à 80, la constante entière `1` de la première instruction `SELECT` est directement convertie dans le type de données de la colonne de destination `ReturnedValue`, c'est-à-dire le type `varchar(255)`. Dans le niveau de compatibilité 90, le type de données du jeu de résultats `UNION` est déterminé avant sa conversion vers la colonne de destination. Pour la deuxième colonne de la première instruction `SELECT`, le type de données est déterminé comme int. Pour la deuxième colonne de la deuxième instruction `SELECT`, le type de données est déterminé comme varchar(4). Étant donné que le type de données int a une priorité supérieure à celle du type de données varchar(4), lors de la détermination des types de données du jeu de résultats `UNION`, la valeur `test` est convertie dans le type de données int, ce qui provoque une erreur de conversion de type de données. `CREATE TABLE #test(ReturnedName varchar(255) NOT NULL, ReturnedValue varchar(255) NULL) INSERT INTO #test SELECT 'col1', 1 UNION ALL SELECT 'test', 'test' DROP TABLE #test`
UPDATETEXT	SQL Server 2005 ne prend pas en charge l'emploi de pointeurs de texte dans les instructions UPDATETEXT qui lisent et écrivent dans les mêmes BLOB (binary large objects) à l'aide du même pointeur de texte. Copiez le BLOB dans une table temporaire ou dans une variable de table, puis réassignez la valeur dans la colonne d'origine.
Mot clé WITH lorsque vous utilisez des indicateurs de table	Dans SQL Server 2005, à quelques exceptions près, les indicateurs de table ne sont pris en charge dans la clause FROM d'une requête que s'ils sont spécifiés à l'aide du mot clé WITH. Pour plus d'informations, consultez FROM (Transact-SQL) et Indicateur de table (T-SQL).
ORDER BY dans une définition de vue	Dans SQL Server 2005, la clause ORDER BY est utilisée dans une définition de vue uniquement pour déterminer les lignes retournées par la clause TOP. La clause ORDER BY ne garantit pas des résultats classés lorsque la vue est interrogée, sauf si la clause ORDER BY est également spécifiée dans la requête proprement dite.
UPDATE avec des indicateurs de verrouillage	Dans SQL Server 2000, les conflits ne sont pas recherchés dans les indicateurs de verrouillage dans une instruction UPDATE lorsque les deux conditions suivantes sont présentes : La table de la clause FROM possède un alias. La même table est référencée comme cible de l'instruction UPDATE sans alias. SQL Server ignore les indicateurs de verrouillage fournis dans la clause FROM et ne génère pas d'erreur en cas de conflit des indicateurs. Dans SQL Server 2005, une erreur est renvoyée en cas de conflit des indicateurs de verrouillage dans ces conditions.

XML

Caractéristique Description

Caractéristique	Description
OPENXML	En raison de changements dans MSXML, OPENXML ne prend plus en charge les prédicats de position non entiers. Dans SQL Server 2005, MSXML 3.0 est le moteur sous-jacent utilisé pour traiter les expressions XPath qui sont utilisées avec les requêtes OPENXML. MSXML 3.0 possède un moteur XPath 1.0 plus conforme dans lequel la sémantique des valeurs non entières dans les prédicats de position a changé. Par exemple, l'expression XPath `a[5.1]` suivante ne renvoie désormais aucun élément, et non plus le cinquième élément `<a>`. Pour corriger ceci, utilisez directement la valeur arrondie. Par exemple, remplacez l'expression précédente par `a[5]`.
Expressions XPath OPENXML	MSXML 3.0 possède un moteur XPath 1.0 plus rigoureux, dans lequel la prise en charge des fonctions suivantes a été supprimée : format-number() formatNumber() current() element-available() function-available() system-property() Pour format-number() et formatNumber(), vous pouvez utiliser Transact-SQL. Pour les autres fonctions qui ne sont plus prises en charge, il n'existe pas de solution de remplacement directe.
Type défini par l'utilisateur 'xml'	Dans SQL Server 2005, xml est un type système réservé. Utilisez sp_rename pour renommer le type, soit avant soit après la mise à niveau, et modifiez l'application pour qu'elle fonctionne avec ce nouveau nom de type.

OPENXML

En raison de changements dans MSXML, OPENXML ne prend plus en charge les prédicats de position non entiers. Dans SQL Server 2005, MSXML 3.0 est le moteur sous-jacent utilisé pour traiter les expressions XPath qui sont utilisées avec les requêtes OPENXML. MSXML 3.0 possède un moteur XPath 1.0 plus conforme dans lequel la sémantique des valeurs non entières dans les prédicats de position a changé.

Par exemple, l'expression XPath a[5.1] suivante ne renvoie désormais aucun élément, et non plus le cinquième élément <a>. Pour corriger ceci, utilisez directement la valeur arrondie. Par exemple, remplacez l'expression précédente par a[5].

Expressions XPath OPENXML

MSXML 3.0 possède un moteur XPath 1.0 plus rigoureux, dans lequel la prise en charge des fonctions suivantes a été supprimée :

format-number()
formatNumber()
current()
element-available()
function-available()
system-property()

Pour format-number() et formatNumber(), vous pouvez utiliser Transact-SQL. Pour les autres fonctions qui ne sont plus prises en charge, il n'existe pas de solution de remplacement directe.

Type défini par l'utilisateur 'xml'

Dans SQL Server 2005, xml est un type système réservé. Utilisez sp_rename pour renommer le type, soit avant soit après la mise à niveau, et modifiez l'application pour qu'elle fonctionne avec ce nouveau nom de type.

Voir aussi

Historique des modifications

Version	Historique
17 novembre 2008	Nouveau contenu : Ajout d'une entrée dans la section Caractéristiques concernant la correspondance du classement de colonne dans les variables de table.
14 avril 2006	Nouveau contenu : Ajout d'une entrée dans la section Transact-SQL relative à l'utilisation de la clause ORDER BY dans une définition de vue. Ajout d'une entrée dans la section Transact-SQL relative à l'utilisation des indicateurs de verrouillage avec l'instruction UPDATE.

Partager via