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 die Verwendung von Python-UDFs nach dem 30. Juni 2026 nicht mehr. Wir werden damit beginnen, es schrittweise durchzusetzen. Weitere Informationen zum Ende der Lebensdauer von Python und zu den Migrationsoptionen finden Sie im Blogbeitrag, der am 30. Juni 2025 veröffentlicht wurde.

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

In diesem Abschnitt werden die Unterschiede zwischen dem ODBC 1.x-Treiber und dem ODBC 2.x-Treiber beschrieben und eine Anleitung zur Migration zum 2.x-Treiber gegeben. 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 Maßnahmen lösen die häufigsten Migrationsprobleme. Die meisten Anwendungen benötigen nur eine Teilmenge davon.

DSN und Verbindungszeichenfolge

  • Überprüfen Sie Ihren DSN auf 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.

  • Legen Sie fest, UseUnicode=true ob Ihre Anwendung von Codes für breite Zeichen (SQL_WVARCHAR,SQL_WCHAR) abhängt. Im ODBC 2.x-Treiber ist die UseUnicode Standardeinstellung auffalse, 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, um diese Objekte weiterhin EXTERNAL TABLE zu sehen. Sie können die EnableTableTypes Option auch auf 0 setzen, um die detaillierten Informationen zum Tabellentyp in die generischen TABLE- und VIEW-Tabellentypen zu normalisieren, wie im folgenden Abschnitt beschrieben.

  • Detaillierte Tabellentypen sind standardmäßig aktiviert. ODBC 2.x aktiviert die EnableTableTypes Option standardmäßig. Der 1.x-Treiber hat diese Option standardmäßig deaktiviert. In der Standardeinstellung 2.x werden detaillierte Typen wie SYSTEM TABLE, SYSTEM VIEW, EXTERNAL TABLE und LOCAL TEMPORARY SQLTables gemeldet. Um jede Tabelle als generischen Typ TABLE und jede Ansicht als VIEW zu melden, setzen Sie EnableTableTypes den Wert auf 0.

  • INTERVALUmwandeln in VARCHAR für Anwendungen, die den Interval-Datentyp nicht unterstützen. Einige Clients unterstützen keine ODBC-Intervalltypen. Für diese Clients geben Sie die Spalte in Ihrer Abfrage um: SELECT col::VARCHAR FROM ...

Code der Anwendung

  • Überprüfen Sie die Einstellungen für das Abfrage-Timeout. ODBC 2.x setzt die ODBC-Spezifikation korrekt SQL_ATTR_QUERY_TIMEOUT durch. 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 „Daten bei der Ausführung“ an. 2.x meldet sich SQL_NEED_LONG_DATA_LEN als Y (1.x gemeldet). N Anwendungen, die SQL_DATA_AT_EXEC Parameter binden, müssen jetzt vorab die gesamte Datenlänge 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.

1.x-Option 2.x-Äquivalent 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. Unter Windows legen Sie dies im Feld Trust Store des DSN-Setup-Dialogfelds fest; das Dialogfeld hat kein CaFile Feld. Wenn beide festgelegt sind, hat 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— wird nicht unterstützt. Unter Windows konnte der 1.x-Treiber das Serverzertifikat anhand des Zertifikatsspeichers des Windows-Systems überprüfen. Der 2.x-Treiber validiert anhand einer CA-Zertifikatsdatei: Er verwendet standardmäßig das mitgelieferte Amazon Redshift-Stammzertifikat oder die Datei, die Sie in oder angeben. TrustStore CaFile

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

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

Änderungen des Datentyps

Die folgende Tabelle zeigt die Amazon Redshift-Datentypzuordnungen, die in ODBC 2.x geändert wurden, um der ODBC-Spezifikation zu entsprechen. Die meisten Anwendungen sind nicht betroffen, da sie Spalten nach Index oder Namen statt 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). Stellen Sie UseUnicode=true diese Option ein, um breite Typen wiederherzustellen.
GEOMETRY/GEOGRAPHY(alsSQL_C_BINARY) Hex-encoded ASCII-Zeichenfolge Rohe Binärbytes

Die von zurückgegebenen COLUMN_SIZE Werte haben sich SQLColumns auch für GEOMETRYGEOGRAPHY, und für die SUPER Datentypen geändert. Diese geben nun NULL zurück, um Spalten ohne Größe gemäß der ODBC-Spezifikation anzuzeigen. Anwendungen, die Puffer basierend auf diesen Daten zuweisen, COLUMN_SIZE müssen NULL verarbeiten, 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 Spektrum- und Datashare-Tabellen werden als gemeldet EXTERNAL TABLE Nehmen Sie das EXTERNAL TABLE in Ihren SQLTables Typfilter auf oder setzen Sie ihn EnableTableTypes auf 0, um die detaillierten Tabellentypen in die generischen TABLE- und VIEW-Typen zu normalisieren.
Pyodbc-Fehler in Intervallspalten pyodbc unterstützt keine ODBC-Intervalltypen Wandelt Intervalle in Abfragen um. VARCHAR
Zeichendaten werden als unerwartete Zeichen angezeigt (Mojibake) UseUnicodeStandardeinstellung geändert auf. false Anwendungen, die Wide-Character (UTF-16) -Daten erwarten, interpretieren Schmalzeichen-Bytes möglicherweise fälschlicherweise als breite Paare, was zu einer verfälschten Ausgabe führt. Die Daten selbst sind unverändert. Geben UseUnicode=true Sie Ihren DSN ein, oder aktualisieren Sie Ihre Anwendung so, dass Spalten als SQL_C_CHAR statt wie gebunden werden. SQL_C_WCHAR
Long-running Abfragen geben Timeout-Fehler zurück SQL_ATTR_QUERY_TIMEOUTwird jetzt erzwungen. ODBC 1.x hat diese Einstellung stillschweigend ignoriert. Erhöhen oder QueryTimeout entfernen Sie Ihren DSN oder setzen Sie ihn in Ihrer Anwendung SQL_ATTR_QUERY_TIMEOUT auf 0.
Einstellung von Renditen SQL_ATTR_CURRENT_CATALOG HY011 Das Attribut kann nicht für eine offene Verbindung gesetzt werden. Das Umschalten 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 in der Zieldatenbank und öffnen Sie sie erneut.
Die Verbindung hängt in Dual-Stack-Umgebungen Einschränkung in Versionen <= 2.1.16 Aktualisieren Sie auf 2.1.17 oder höher.
Beim Analysieren von Fehlermeldungen werden unerwartete Ergebnisse zurückgegeben Nachrichtenformat geändert; SQLSTATE-Codes unverändert Analysieren Sie SQLSTATE-Codes anstelle des Nachrichtentexts.
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 gesamte Datenlä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 müssen 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 Amazon Redshift-Anmeldung zur ODBC-Treiberänderung. GitHub

Weitere Informationen