Mise à jour d'une application depuis SQL Server 2005 Native Client

  • Article

S’applique à :SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)

Important

SQL Server Native Client (souvent abrégé en SNAC) a été supprimé dans SQL Server 2022 (16.x) et SQL Server Management Studio 19 (SSMS). SQL Server Native Client (SQLNCLI ou SQLNCLI11) et le fournisseur Microsoft OLE DB pour SQL Server (SQLOLEDB) hérité ne sont pas recommandés dans les nouveaux développements. Utilisez à la place le nouveau Microsoft OLE DB Driver (MSOLEDBSQL) pour SQL Server ou le Microsoft ODBC Driver for SQL Server le plus récent. Pour SQLNCLI fourni en tant que composant du moteur de base de données SQL Server (versions 2012 à 2019), consultez cette exception de support du cycle de vie.

Cette rubrique décrit les changements cassants dans SQL Server Native Client depuis SQL Server Native Client dans SQL Server 2005 (9.x).

Lorsque vous effectuez une mise à niveau de Microsoft Data Access Components (MDAC) vers SQL Server Native Client, vous pouvez également voir des différences de comportement. Pour plus d’informations, consultez Mise à jour d’une application pour SQL Server Native Client à partir de MDAC.

SQL Server Native Client 9.0 livré avec SQL Server 2005 (9.x). SQL Server Native Client 10.0 livré avec SQL Server 2008 (10.0.x). SQL Server Native Client 10.5 livré avec SQL Server 2008 R2 (10.50.x). SQL Server Native Client 11.0 livré avec SQL Server 2012 (11.x) et SQL Server 2014 (12.x).

Modification du comportement dans SQL Server Native Client depuis SQL Server 2005 (9.x) Description
OLE DB effectue un remplissage uniquement à l'échelle définie. Pour les conversions où les données converties sont envoyées au serveur, SQL Server Native Client (à compter de SQL Server 2008 (10.0.x)) affiche des zéros de fin dans les données uniquement jusqu’à la longueur maximale des valeurs datetime. SQL Server Native Client 9.0 effectuaient un remplissage à neuf chiffres.
Validez DBTYPE_DBTIMESTAMP pour ICommandWithParameter::SetParameterInfo. SQL Server Native Client (à partir de SQL Server 2008 (10.0.x)) implémente la spécification OLE DB pour bScale dans ICommandWithParameter::SetParameterInfo pour qu’elle soit définie sur la précision fractionnaire de secondes pour DBTYPE_DBTIMESTAMP.
La procédure stockée sp_columns retourne maintenant "NO" au lieu de "NO " pour la colonne IS_NULLABLE. À compter de SQL Server Native Client 10.0 (SQL Server 2008 (10.0.x)), sp_columns procédure stockée retourne désormais « NO » au lieu de « NO » pour une colonne IS_NULLABLE.
SQLSetDescRec, SQLBindParameter et SQLBindCol effectuent désormais une vérification de cohérence. Avant SQL Server Native Client 10.0, la définition de SQL_DESC_DATA_PTR n’a pas causé de case activée de cohérence pour un type descripteur dans SQLSetDescRec, SQLBindParameter ou SQLBindCol.
SQLCopyDesc effectue désormais la vérification de la cohérence du descripteur. Avant SQL Server Native Client 10.0, SQLCopyDesc n’a pas effectué de case activée de cohérence lorsque le champ SQL_DESC_DATA_PTR a été défini sur un enregistrement particulier.
SQLGetDescRec n’effectue plus de case activée de cohérence de descripteur. Avant SQL Server Native Client 10.0, SQLGetDescRec effectuait une cohérence de descripteur case activée lorsque le champ SQL_DESC_DATA_PTR était défini. Cela n’était pas requis par la spécification ODBC et dans SQL Server Native Client 10.0 (SQL Server 2008 (10.0.x)) et versions ultérieures, cette case activée de cohérence n’est plus effectuée.
Erreur différente retournée lorsque la date est hors limites. Pour le type datetime, un numéro d’erreur différent est retourné par SQL Server Native Client (à compter de SQL Server 2008 (10.0.x)) pour une date hors plage par rapport à ce qui a été retourné dans les versions antérieures.

Plus précisément, SQL Server Native Client 9.0 a retourné 22007 pour toutes les valeurs d’année hors plage dans les conversions de chaîne en datetime, et SQL Server Native Client à compter de la version 10.0 (SQL Server 2008 (10.0.x)) retourne 22008 lorsque la date est dans la plage prise en charge par datetime2 mais en dehors de la plage prise en charge par datetime ou smalldatetime.
La valeur datetime tronque les fractions de seconde et n’arrondit pas si cela entraîne une modification du jour. Avant SQL Server Native Client 10.0, le comportement client pour les valeurs datetime envoyées au serveur consistait à les arrondir au 1/300e de seconde. À compter de SQL Server Native Client 10.0, ce scénario entraîne une troncation de fractions de secondes si l’arrondi change le jour.
Troncation possible des secondes pour la valeur datetime. Une application créée avec SQL Server 2008 (10.0.x) Native Client (ou version ultérieure) qui se connecte à un serveur SQL Server 2005 tronquera en secondes et fractions de secondes pour la partie temporelle des données envoyées au serveur si vous liez à une colonne datetime avec un identificateur de type DBTYPE_DBTIMESTAMP (OLE DB) ou SQL_TIMESTAMP (ODBC) et une échelle de 0.

Par exemple :

Données d'entrée : 1994-08-21 21:21:36.000

Données insérées : 1994-08-21 21:21:00.000
La conversion de données OLE DB de DBTYPE_DBTIME vers DBTYPE_DATE ne peut plus provoquer de changement de jour. Avant SQL Server Native Client 10.0, si la partie heure d'un DBTYPE_DATE était à moins d'une demi-seconde de minuit, le code de conversion OLE DB provoquait le changement de jour. À compter de SQL Server Native Client 10.0, le jour ne change pas (les fractions de secondes sont tronquées et non arrondies).
Modifications de conversion IBCPSession::BCColFmt. À compter de SQL Server Native Client 10.0, lorsque vous utilisez IBCPSession::BCOColFmt pour convertir SQLDATETIME ou SQLDATETIME en type de chaîne, une valeur fractionnaire est exportée. Par exemple, lors de la conversion du type SQLDATETIME en type SQLNVARCHARMAX, les versions antérieures de SQL Server Native Client retournées

1989-02-01 00:00:00. SQL Server Native Client 10.0 et versions ultérieures retournent 1989-02-01 00:00:00.0000000000.
La taille des données envoyées doit correspondre à la longueur spécifiée dans SQL_LEN_DATA_AT_EXEC. Lors de l'utilisation de SQL_LEN_DATA_AT_EXEC, la taille des données doit correspondre à la longueur que vous avez spécifiée avec SQL_LEN_DATA_AT_EXEC. Vous pouvez utiliser SQL_DATA_AT_EXEC, mais l'utilisation de SQL_LEN_DATA_AT_EXEC présente certains avantages en matière de performances.
Les applications personnalisées qui utilisent l'API BCP peuvent maintenant afficher un avertissement. L'API BCP génère un message d'avertissement si la longueur des données est supérieure à la longueur spécifiée pour un champ pour tous les types. Auparavant, cet avertissement était affiché uniquement pour les types caractère, et non pour tous les types.
L’insertion d’une chaîne vide dans un sql_variant lié en tant que type date/heure génère une erreur. Dans SQL Server Native Client 9.0, l’insertion d’une chaîne vide dans un sql_variant lié en tant que type date/heure ne générait pas d’erreur. SQL Server Native Client 10.0 (et versions ultérieures) génère correctement une erreur dans cette situation.
Validation des paramètres _TIMESTAMP SQL_C_TYPE et DBTYPE_DBTIMESTAMP plus stricte. Avant SQL Server 2008 (10.0.x) Native Client, les valeurs datetime étaient arrondies pour s’adapter à l’échelle des colonnes datetime et smalldatetime par SQL Server. SQL Server 2008 (10.0.x) Native Client (et versions ultérieures) applique les règles de validation plus strictes définies dans la spécification de cœur ODBC pendant une fraction de secondes. Si une valeur de paramètre ne peut pas être convertie au type SQL à l'aide de l'échelle spécifiée ou déduite de la liaison de client sans troncation des chiffres de fin, une erreur est retournée.
SQL Server peut retourner des résultats différents lorsque le déclencheur s’exécute. Des modifications apportées dans SQL Server 2008 (10.0.x) ont pu amener une application à avoir des résultats différents retournés par une instruction, ce qui a entraîné l’exécution d’un déclencheur quand NOCOUNT OFF était actif. Dans ce cas, votre application peut générer une erreur. Pour résoudre cette erreur, définissez NOCOUNT ON dans le déclencheur ou appelez SQLMoreResults pour passer au résultat suivant.

Voir aussi

Programmation de SQL Server Native Client