Mise à jour d'une application depuis SQL Server 2005 Native Client
S’applique à :
SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW)
Important
SQL Server Native Client (SNAC) n’est pas fourni avec :
- SQL Server 2022 (16.x) et version ultérieure
- SQL Server Management Studio 19 et versions ultérieures
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.
Pour les nouveaux projets, utilisez l'un des pilotes suivants :
Pour SQLNCLI qui est fourni en tant que composant du moteur de base de données SQL Server (versions 2012 à 2019), consultez cette exception du cycle de vie du support.
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 vers 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 les zéros de fin dans les données uniquement jusqu’à la durée 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 (à compter de SQL Server 2008 (10.0.x)) implémente l’exigence OLE DB pour bScale dans ICommandWithParameter ::SetParameterInfo à définir sur la précision des fractions 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, le paramètre SQL_DESC_DATA_PTR n’a pas généré de vérification de cohérence pour tout type de descripteur dans SQLSetDescRec, SQLBindParameter ou SQLBindCol. |
| SQLCopyDesc effectue désormais une vérification de cohérence de descripteur. | Avant SQL Server Native Client 10.0, SQLCopyDesc n’a pas effectué de vérification de cohérence lorsque le champ SQL_DESC_DATA_PTR a été défini sur un enregistrement particulier. |
| SQLGetDescRec n’effectue plus de vérification de cohérence de descripteur. | Avant SQL Server Native Client 10.0, SQLGetDescRec a effectué une vérification de cohérence de descripteur lorsque le champ SQL_DESC_DATA_PTR a été défini. Cela n’a pas été 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 vérification de cohérence n’est plus effectuée. |
| Erreur différente retournée lorsque la date est hors limites. | Pour le type datetime , un autre numéro d’erreur est retourné par SQL Server Native Client (à compter de SQL Server 2008 (10.0.x)) pour une date hors plage que celle retournée 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înes en datetime, et SQL Server Native Client commençant par la version 10.0 (SQL Server 2008 (10.0.x)) retourne 22008 lorsque la date est 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 provoque 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 tronque les secondes et les fractions de secondes pour la partie de temps des données envoyées au serveur si vous liez à une colonne datetime avec un identificateur de type de 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 de type SQLDATETIME en type SQLNVARCHARMAX, 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.0000000. |
| 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 ont été arrondies pour correspondre à 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 base ODBC pendant des secondes fractionnaires. 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
Commentaires
Prochainement : Tout au long de l'année 2024, nous supprimerons progressivement les GitHub Issues en tant que mécanisme de retour d'information pour le contenu et nous les remplacerons par un nouveau système de retour d'information. Pour plus d’informations, voir: https://aka.ms/ContentUserFeedback.
Soumettre et afficher des commentaires pour