View a markdown version of this page

Unterschiede zwischen den Versionen 2.x und 1.x des ODBC-Treibers - Amazon Redshift
Die wichtigsten Unterschiede, die es zu beheben giltVerbindungszeichenfolge und DSN-OptionenÄnderungen des DatentypsPost-migration ProblembehandlungAktualisierung von einer älteren ODBC 2.x-VersionWeitere Informationen

Amazon Redshift unterstützt ab Patch 198 nicht mehr die Erstellung neuer Python-UDFs. Bestehende Python-UDFs werden bis zum 30. Juni 2026 weiterhin funktionieren. Weitere Informationen finden Sie im Blog-Posting.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Unterschiede zwischen den Versionen 2.x und 1.x des ODBC-Treibers

Dieser Abschnitt beschreibt die Unterschiede zwischen dem ODBC 1.x-Treiber und dem ODBC 2.x-Treiber und bietet Anleitungen zur Migration zum 2.x-Treiber. Es beschreibt die Änderungen, die sich auf Ihre Anwendung auswirken könnten, und wie Sie diese beheben können.

Die wichtigsten Unterschiede, die es zu beheben gilt

Die folgenden Aktionen lösen die häufigsten Migrationsprobleme. Die meisten Anwendungen benötigen nur eine Teilmenge davon.

DSN und Verbindungszeichenfolge

  • Suchen Sie in Ihrem DSN nach Treiberoptionen, die möglicherweise entfernt oder umbenannt wurden. Einige ODBC 1.x-Treiberoptionen werden im ODBC 2.x-Treiber nicht unterstützt. Andere wurden umbenannt. Details dazu finden Sie unter Verbindungszeichenfolge und DSN-Optionen.

  • Stellen Sie einUseUnicode=true, ob Ihre Anwendung auf Codes vom Typ „Breite Zeichen“ (SQL_WVARCHAR,SQL_WCHAR) angewiesen ist. Im ODBC 2.x-Treiber ist UseUnicode standardmäßigfalse, was schmale Zeichentypen meldet.

  • Verschieben Sie die Protokollierungseinstellungen in den Abschnitt. [ODBC] Unter Linux und macOS LogLevel und LogPath muss im globalen [ODBC] Abschnitt von festgelegt werdenodbc.ini, nicht in einem einzelnen DSN-Abschnitt.

Abfrage und Schema

  • EXTERNAL TABLEIn SQLTables Typfilter einbeziehen. In ODBC 2.x werden sowohl Amazon Redshift Spectrum-Tabellen als auch Datashare-Tabellen als gemeldet. EXTERNAL TABLE Wenn Sie SQLTables nach Typ filtern, fügen Sie hinzu, EXTERNAL TABLE damit diese Objekte weiterhin angezeigt werden.

  • Umwandlung INTERVAL in VARCHAR für Anwendungen, die den Intervall-Datentyp nicht unterstützen. Einige Clients unterstützen ODBC-Intervalltypen nicht. Geben Sie für diese Clients die Spalte in Ihrer Abfrage wie folgt ein: SELECT col::VARCHAR FROM ...

Anwendungscode

  • Überprüfen Sie die Timeout-Einstellungen für Abfragen. ODBC 2.x setzt die Anforderungen SQL_ATTR_QUERY_TIMEOUT gemäß der ODBC-Spezifikation korrekt um. ODBC 1.x hat diese Einstellung stillschweigend ignoriert. Long-running Abfragen, die zuvor erfolgreich waren, schlagen jetzt möglicherweise mit einem Timeout-Fehler fehl. Überprüfen Sie Ihre Timeout-Werte und passen Sie sie nach Bedarf an.

  • Geben Sie die Datenlänge für die Parameter „Data-at-Execution“ an. 2.x meldet SQL_NEED_LONG_DATA_LEN als Y (1.x gemeldet). N Anwendungen, die SQL_DATA_AT_EXEC Parameter binden, müssen jetzt die gesamte Datenlänge im Voraus angeben. StrLen_or_IndPtr

Verbindungszeichenfolge und DSN-Optionen

Die folgende Tabelle zeigt ODBC 1.x-Treiberoptionen, die entweder umbenannt wurden oder direkte Entsprechungen im ODBC 2.x-Treiber haben.

Option 1.x Äquivalent zu 2.x Hinweise
MaxLongVarChar MaxLongVarcharSize Die Standardeinstellung wurde von 8190 auf 65535 geändert.
ConnectionTimeout LoginTimeout Derselbe Verbindungs-Timeout, umbenannt. Der Standardwert ist 0 (kein Timeout).
VpcEndpointUrl vpc_endpoint_url
SSLCertPath TrustStore oder CaFile Pfad zu einem CA-Zertifikat, das zur Überprüfung des Servers verwendet wird. Stellen Sie dies unter Windows im Feld Trust Store des DSN-Setup-Dialogfelds ein. Das Dialogfeld hat kein CaFile Feld. Wenn beide gesetzt sind, hat dies TrustStore Priorität.

Die folgenden 1.x-Optionen werden im aktuellen 2.x-Treiber nicht unterstützt. Der 2.x-Treiber ignoriert sie, sodass sie Ihre Verbindung nicht beeinträchtigen. Sie aus Ihrem DSN zu entfernen ist optional, wird aber empfohlen, um Verwirrung zu vermeiden.

  • SingleRowMode— um den Client-Speicher zu begrenzen, verwenden Sie StreamingCursorRows stattdessen.

  • UseSystemTrustStore— nicht unterstützt. Unter Windows konnte der 1.x-Treiber das Serverzertifikat anhand des Windows-Systemzertifikatsspeichers validieren. Der 2.x-Treiber validiert anhand einer CA-Zertifikatsdatei: Er verwendet standardmäßig das mitgelieferte Amazon Redshift Redshift-Stammzertifikat oder die Datei, die Sie in oder angeben. TrustStore CaFile

  • BoolsAsChar— Wenn Ihre Anwendung darauf angewiesen war, dass BOOLEAN-Spalten als "0" und "1" strings (SQL_VARCHAR) zurückgegeben wurden, wandeln Sie die Spalte beispielsweise VARCHAR in Ihrer Abfrage um. SELECT col::VARCHAR FROM ...

  • TextAsLongVarchar,CheckCertRevocation,EnableAwsSdkLogs,UseLogPrefix,,Locale, UseDeclareFetch UseMultipleStatementsEnforceSingleStatement, EnableTableTypes — kein Äquivalent in der aktuellen Version. Das Amazon Redshift Redshift-Team prüft derzeit Äquivalente oder Alternativen für diese Optionen in future Versionen.

Die vollständige Liste der unterstützten 2.x-Optionen finden Sie unter. ODBC-Treiberoptionen

Änderungen des Datentyps

Die folgende Tabelle zeigt Amazon Redshift Redshift-Datentypzuordnungen, die in ODBC 2.x geändert wurden, um der ODBC-Spezifikation zu entsprechen. Die meisten Anwendungen sind davon nicht betroffen, da sie Spalten eher nach Index oder Namen als nach Typcode binden.

Amazon-Redshift-Datentyp ODBC 1.x ODBC 2.x
DOUBLE PRECISION SQL_FLOAT(6) SQL_DOUBLE (8)
INTERVAL YEAR TO MONTH SQL_VARCHAR(12), Text SQL_INTERVAL_YEAR_TO_MONTH(107), Intervallstruktur
INTERVAL DAY TO SECOND SQL_VARCHAR(12), Text SQL_INTERVAL_DAY_TO_SECOND(110), Intervallstruktur
VARCHAR / CHAR / TEXT Breite Typen (SQL_WVARCHAR,SQL_WCHAR,SQL_WLONGVARCHAR); Standard UseUnicode=true Schmale Typen (SQL_VARCHAR,SQL_CHAR,SQL_LONGVARCHAR). Legt festUseUnicode=true, dass breite Typen wiederhergestellt werden.
GEOMETRY/GEOGRAPHY(alsSQL_C_BINARY) Hex-encoded ASCII-Zeichenfolge Unformatierte Binärbytes

Die von zurückgegebenen COLUMN_SIZE Werte haben sich SQLColumns auch für die SUPER Datentypen GEOMETRYGEOGRAPHY, und geändert. Diese geben nun NULL zurück, um Spalten ohne Größe gemäß der ODBC-Spezifikation anzuzeigen. Anwendungen, die Puffer auf der Grundlage von NULL zuweisen, COLUMN_SIZE müssen mit NULL umgehen, indem sie eine Standardpuffergröße verwenden.

Post-migration Problembehandlung

In der folgenden Tabelle werden häufig auftretende Probleme beschrieben, die nach der Migration auftreten können, und deren Behebung.

Symptom Ursache Vorgehensweise
Externe Tabellen sind im Schemabrowser nicht sichtbar Spectrum- und Datashare-Tabellen werden gemeldet als EXTERNAL TABLE In den EXTERNAL TABLE SQLTables Typfilter einbeziehen.
Pyodbc-Fehler in Intervallspalten pyodbc unterstützt keine ODBC-Intervalltypen Wandelt Intervalle in Abfragen um. VARCHAR
Zeichendaten werden als unerwartete Zeichen angezeigt (Mojibake) UseUnicodeDie Standardeinstellung wurde auf geändert. false Anwendungen, die Daten mit breiten Zeichen (UTF-16) erwarten, interpretieren Bytes mit schmalen Zeichen möglicherweise falsch als breite Paare, was zu einer verstümmelten Ausgabe führt. Die Daten selbst sind unverändert. Legen Sie UseUnicode=true in Ihrem DSN fest, oder aktualisieren Sie Ihre Anwendung so, dass Spalten wie SQL_C_CHAR anstelle von SQL_C_WCHAR gebunden werden.
Long-running Abfragen geben Timeout-Fehler zurück SQL_ATTR_QUERY_TIMEOUTist jetzt erzwungen. ODBC 1.x hat diese Einstellung stillschweigend ignoriert. Erhöhen oder entfernen Sie es QueryTimeout aus Ihrem DSN oder setzen Sie es in Ihrer Anwendung SQL_ATTR_QUERY_TIMEOUT auf 0.
Die Einstellung kehrt zurück SQL_ATTR_CURRENT_CATALOG HY011 Das Attribut kann nicht für eine offene Verbindung festgelegt werden. Das Wechseln von Datenbanken bei einer offenen Verbindung wird nicht unterstützt. Legen Sie das Attribut fest, bevor Sie eine Verbindung herstellen, oder schließen Sie die Verbindung zur Zieldatenbank und öffnen Sie sie erneut.
In Dual-Stack-Umgebungen hängt die Verbindung Einschränkung in Versionen <= 2.1.16 Führen Sie ein Upgrade auf 2.1.17 oder höher durch.
Das Analysieren von Fehlermeldungen liefert unerwartete Ergebnisse Nachrichtenformat geändert; SQLSTATE-Codes unverändert Analysiert SQLSTATE-Codes anstelle von Nachrichtentext.
Data-at-execution Die Parameterbindung verhält sich anders SQL_NEED_LONG_DATA_LENwurde von FALSE auf TRUE geändert; Anwendungen, die dies verwenden, SQL_DATA_AT_EXEC müssen jetzt die Gesamtdatenlänge im Voraus angeben Geben Sie StrLen_or_IndPtr beim Binden von SQL_DATA_AT_EXEC Parametern den Längenwert ein.
Treiberprotokolle werden nicht generiert LogLevelund LogPath muss sich im [ODBC] globalen Bereich von befindenodbc.ini, nicht in einzelnen DSN-Abschnitten Verschieben Sie die Protokollierungseinstellungen von Ihrem DSN in den [ODBC] Abschnitt.

Aktualisierung von einer älteren ODBC 2.x-Version

Wenn Sie bereits eine ältere ODBC 2.x-Version verwenden, führen Sie ein Upgrade auf die neueste Version durch. Eine vollständige Liste der Verbesserungen und Bugfixes für alle Versionen finden Sie in der Anmeldung zur Änderung des Amazon Redshift ODBC-Treibers. GitHub

Weitere Informationen