Aktualisieren einer Anwendung von SQL Server 2005 Native Client
Gilt für:
SQL Server Azure SQL-Datenbank Azure SQL verwaltete Instanz Azure Synapse Analytics Analytics Platform System (PDW)
Wichtig
SQL Server Native Client (SNAC) wird nicht ausgeliefert mit:
- SQL Server 2022 (16.x) und höher
- SQL Server Management Studio (19 und höher)
Der SQL Server Native Client (SQLNCLI oder SQLNCLI11) und der Microsoft OLE DB-Legacyanbieter für SQL Server (SQLOLEDB) werden für neue Anwendungsentwicklungen nicht empfohlen.
Für neue Projekte verwenden Sie einen der folgenden Treiber:
Informationen zu SQLNCLI, das als Komponente der SQL Server Datenbank-Engine (Versionen 2012 bis 2019) ausgeliefert wird, finden Sie in dieser Ausnahme für den Supportlebenszyklus.
In diesem Thema werden die änderungen in SQL Server Native Client seit SQL Server Native Client in SQL Server 2005 (9.x) erläutert.
Wenn Sie ein Upgrade von Microsoft Data Access Components (MDAC) auf SQL Server Native Client durchführen, werden möglicherweise auch einige Verhaltensunterschiede angezeigt. Weitere Informationen finden Sie unter Aktualisieren einer Anwendung auf SQL Server Native Client von MDAC.
SQL Server Native Client 9.0 war im Lieferumfang von SQL Server 2005 (9.x) enthalten. SQL Server Native Client 10.0 war im Lieferumfang von SQL Server 2008 (10.0.x) enthalten. SQL Server Native Client 10.5 war im Lieferumfang von SQL Server 2008 R2 (10.50.x) enthalten. SQL Server Native Client 11.0 war im Lieferumfang von SQL Server 2012 (11.x) und SQL Server 2014 (12.x) enthalten.
| Verhalten in SQL Server Native Client Seit SQL Server 2005 (9.x) geändert | Beschreibung |
|---|---|
| OLE DB füllt nur Zahlen bis zur definierten Anzahl von Dezimalstellen auf. | Für Konvertierungen, bei denen konvertierte Daten an den Server gesendet werden, werden sql Server Native Client (beginnend mit SQL Server 2008 (10.0.x)) Pads nach Nullen in Daten nur bis zur maximalen Länge der Datumszeitwerte verwendet. In SQL Server Native Client 9.0 wurden Zahlen bis zu 9 Stellen aufgefüllt. |
| Überprüfen Sie DBTYPE_DBTIMESTAMP auf ICommandWithParameter::SetParameterInfo. | SQL Server Native Client (beginnend mit SQL Server 2008 (10.0.x)) implementiert die OLE DB-Anforderung für bScale in ICommandWithParameter::SetParameterInfo, um für DBTYPE_DBTIMESTAMP auf die Genauigkeit der Bruchsekunden festzulegen. |
| Die gespeicherte Prozedur sp_columns gibt jetzt für die Spalte IS_NULLABLE „NO“ statt „NO“ zurück. | Ab SQL Server Native Client 10.0 (SQL Server 2008 (10.0.x)) gibt sp_columns gespeicherte Prozedur jetzt "NO" anstelle von "NO" für eine IS_NULLABLE Spalte zurück. |
| SQLSetDescRec, SQLBindParameter und SQLBindCol führen jetzt die Konsistenzüberprüfung durch. | Vor SQL Server Native Client 10.0 hat die Einstellung SQL_DESC_DATA_PTR keine Konsistenzüberprüfung für einen Deskriptortyp in SQLSetDescRec, SQLBindParameter oder SQLBindCol verursacht. |
| SQLCopyDesc führt jetzt die Überprüfung der Konsistenzüberprüfung durch. | Vor SQL Server Native Client 10.0 hat SQLCopyDesc keine Konsistenzüberprüfung durchgeführt, wenn das feld SQL_DESC_DATA_PTR für einen bestimmten Datensatz festgelegt wurde. |
| SQLGetDescRec führt keine Deskriptorkonsistenzüberprüfung mehr durch. | Vor SQL Server Native Client 10.0 hat SQLGetDescRec eine Deskriptorkonsistenzüberprüfung ausgeführt, wenn das SQL_DESC_DATA_PTR Feld festgelegt wurde. Dies war nicht von der ODBC-Spezifikation und in SQL Server Native Client 10.0 (SQL Server 2008 (10.0.x)) und höheren Versionen erforderlich, diese Konsistenzüberprüfung wird nicht mehr ausgeführt. |
| Es wird ein anderer Fehler zurückgegeben, wenn das Datum außerhalb des zulässigen Bereichs liegt. | Für den Datetime-Typ wird eine andere Fehlernummer von SQL Server Native Client (ab SQL Server 2008 (10.0.x)) für ein Datum außerhalb des Bereichs zurückgegeben, als in früheren Versionen zurückgegeben wurde. Insbesondere gibt SQL Server Native Client 9.0 22007 für alle Werte des Bereichs Jahr in Zeichenfolgenkonvertierungen in Datetime zurück, und SQL Server Native Client beginnend mit Version 10.0 (SQL Server 2008 (10.0.x)) gibt 22008 zurück, wenn sich das Datum innerhalb des bereichs befindet, der von datetime2 unterstützt wird, aber außerhalb des Bereichs, der von Datetime oder Smalldatetime unterstützt wird. |
| Bei datetime-Werten werden Sekundenbruchteile abgeschnitten, und diese Werte werden nicht gerundet, wenn sich durch die Rundung der Tag ändern würde. | In Versionen vor SQL Server Native Client 10.0 wurden datetime-Werte, die an den Server gesendet wurden, vom Client auf das nächste 1/300stel einer Sekunde gerundet. Beginnend mit SQL Server Native Client 10.0 verursacht dieses Szenario einen Abbruch von Bruch sekunden, wenn sich das Runden des Tages ändert. |
| Möglicherweise werden vom datetime-Wert Sekunden abgeschnitten. | Eine Anwendung, die mit SQL Server 2008 (10.0.x) nativem Client (oder höher) erstellt wurde, der eine Verbindung mit einem SQL Server 2005-Server herstellt, schneidet Sekunden und Bruchteile von Sekunden für den Zeitteil der an den Server gesendeten Daten ab, wenn Sie eine Bindung an eine Datetime-Spalte mit einem Typbezeichner von DBTYPE_DBTIMESTAMP (OLE DB) oder SQL_TIMESTAMP (ODBC) und einer Skalierung von 0 herstellen. Zum Beispiel: Eingabedaten: 1994-08-21 21:21:36.000 Einfügedaten: 1994-08-21 21:21:00.000 |
| Die OLE DB-Datenkonvertierung von DBTYPE_DBTIME in DBTYPE_DATE kann keine Änderung des Tages mehr bewirken. | In früheren Versionen als SQL Server Native Client 10.0 bewirkte der OLE DB-Konvertierungscode eine Änderung des Tages, wenn der Uhrzeitanteil eines DBTYPE_DATE-Werts innerhalb einer halben Sekunde vor Mitternacht lag. Ab SQL Server Native Client 10.0 ändert sich der Tag nicht (Bruch sekunden werden abgeschnitten und nicht gerundet). |
| IBCPSession::BCColFmt-Konvertierungsänderungen. | Ab SQL Server Native Client 10.0 wird beim Verwenden von IBCPSession::BCOColFmt zum Konvertieren von SQLDATETIME oder SQLDATETIME in einen Zeichenfolgentyp ein Bruchwert exportiert. Beispiel: Beim Konvertieren des Typs "SQLDATETIME" in den Typ "SQLNVARCHARMAX" wurden frühere Versionen von SQL Server Native Client zurückgegeben. 1989-02-01 00:00:00. SQL Server Native Client 10.0 und höhere Versionen geben 1989-02-01 00:00:00:00.000000 zurück. |
| Die Größe der gesendeten Daten muss der in SQL_LEN_DATA_AT_EXEC angegebenen Länge entsprechen. | Wenn SQL_LEN_DATA_AT_EXEC verwendet wird, muss die Größe der Daten der Länge entsprechen, die Sie in SQL_LEN_DATA_AT_EXEC angegeben haben. Sie können SQL_DATA_AT_EXEC verwenden, aber der Einsatz von SQL_LEN_DATA_AT_EXEC bietet potenzielle Leistungsvorteile. |
| Benutzerdefinierte Anwendungen, die die BCP API verwenden, können jetzt Warnungen anzeigen. | Die BCP API erzeugt jetzt für alle Typen Warnmeldungen, wenn die Datenlänge die angegebene Länge eines Felds überschreitet. Früher wurde diese Warnung nur für Zeichentypen ausgegeben, aber nicht für alle Typen. |
| Wenn eine leere Zeichenfolge in eine sql_variant-Spalte eingefügt wird, die an einen Datum-/Uhrzeit-Typ gebunden wurde, dann wird dadurch ein Fehler erzeugt. | In SQL Server Native Client 9.0 wurde kein Fehler erzeugt, wenn eine leere Zeichenfolge in eine sql_variant-Spalte eingefügt wurde, die an einen Datum-/Uhrzeit-Typ gebunden war. SQL Server Native Client 10.0 (und höher) generiert in dieser Situation einen Fehler. |
| Strengere SQL_C_TYPE _TIMESTAMP- und DBTYPE_DBTIMESTAMP-Parameterüberprüfung | Vor SQL Server 2008 (10.0.x) wurden Datumstimewerte gerundet, um die Skalierung von Datetime- und Smalldatetime-Spalten von SQL Server anzupassen. SQL Server 2008 (10.0.x) Native Client (und höher) wendet die strengeren Gültigkeitsprüfungsregeln an, die in der ODBC-Kernspezifikation für Bruchteile sekunden definiert sind. Wenn ein Parameterwert nicht mit den angegebenen oder vom Client implizierten Dezimalstellen in den SQL-Typ konvertiert werden kann, ohne dass nachfolgende Stellen abgeschnitten werden, dann wird ein Fehler zurückgegeben. |
| SQL Server kann andere Ergebnisse zurückgeben, wenn ein Trigger ausgeführt wird. | In SQL Server 2008 (10.0.x) eingeführte Änderungen können bewirken, dass für eine Anwendung andere Ergebnisse von einer Anweisung zurückgegeben werden, die die Ausführung eines Triggers verursachen, wenn NOCOUNT OFF gültig war. In dieser Situation kann die Anwendung einen Fehler generieren. Um diesen Fehler zu beheben, legen Sie NOCOUNT ON im Trigger fest, oder rufen Sie SQLMoreResults auf, um zum nächsten Ergebnis zu wechseln. |
Weitere Informationen
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für