Kompatibilitätsmatrix
In der folgenden Tabelle wird die Kompatibilität der Typen von Anwendungen und Treibern beschrieben, die zuvor in diesem Abschnitt definiert wurden.
| Anwendungstyp und Version |
32-Bit-ODBC 2.x-Treiber |
ODBC 3.x driver |
ODBC 3.8-Treiber | ISO- und Open Group-kompatibler Treiber |
|---|---|---|---|---|
| 16-Bit-Anwendung, jede Version | Kompatibel | Kompatibel | Kompatibel | Kompatibel |
| Reine 2.x-Anwendung | Kompatibel | Kompatibel | Kompatibel | Nicht kompatibel[3] |
| Reine 2.x neu kompilierte Anwendung | Kompatibel | Kompatibel[1] | Kompatibel[1] | Nicht kompatibel[3] |
| Reine 2.x-Unicode-Anwendung | Kompatibel | Kompatibel[1] | Kompatibel[1] | Nicht kompatibel[3] |
| Pure Open Group und ISO-kompatible Anwendung | Nicht kompatibel | Kompatibel[2] | Kompatibel[2] | Kompatibel[2] |
| Reine 3.0-Anwendung | Nicht kompatibel | Kompatibel | Kompatibel | Nicht kompatibel[4] |
| Reine 3.5-Anwendung | Nicht kompatibel | Kompatibel | Kompatibel | Nicht kompatibel[4] |
| Reine Anwendung 3.8 (oder höher) | Nicht kompatibel [5] | Nicht kompatibel [5] | Kompatibel | Nicht kompatibel [4] |
| Anwendung ersetzt | Kompatibel | Kompatibel | Kompatibel | Nicht kompatibel[3] |
[1] Die Anwendung muss mithilfe von ODBC 3.5-Headern (oder höher) mit der UNICODE-Option (sofern es sich um eine Unicode-Anwendung handelt) neu kompilieren und ODBCVER auf 0x0250 festlegen.
[2] Die Anwendung muss mit ODBC 3.5-Headern (oder höher) kompilieren und mit dem ODBC-Treiber-Manager verknüpfen. Außerdem muss die Kopfzeilenkennzeichnung ODBC_STD festgelegt werden.
[3] Diese Konfiguration kann möglicherweise nicht funktionieren, da es Features in ODBC 2.x gibt, die nicht in den Standards enthalten sind, z. B. Lesezeichen.
[4] Diese Konfiguration kann möglicherweise nicht funktionieren, da es Features in ODBC 3.x gibt, die sich nicht in den Standards befinden, z. B. Lesezeichen.
[5] Diese Konfiguration kann potenziell fehlschlagen, da es Features in ODBC 3.8 gibt, die sich nicht in ODBC 2.x- oder 3.x-Treibern befinden, z. B. treiberspezifische C-Datentypen in ODBC.
Treiber-Manager-Kompatibilität
Eine ODBC 3.0-Anwendung, die mit allen Treiber-Manager-Versionen arbeiten muss, sollte beim Start die folgenden Schritte ausführen:
Weisen Sie ein Umgebungshandle zu.
Legen Sie das attribut SQL_ATTR_ODBC_VERSION Umgebung auf SQL_OV_ODBC3_80 fest. Wenn der Treiber-Manager SQL_ERROR zurückgibt, ist der Treiber-Manager älter als 3.8. Setzen Sie SQL_ATTR_ODBC_VERSION entsprechend dem Treiber-Manager auf SQL_OV_ODBC3 oder SQL_OV_ODBC2 zurück.
Weisen Sie einen Verbindungsziehpunkt zu.
Herstellen einer Verbindung.
Rufen Sie SQLGetInfo für SQL_DRIVER_ODBC_VER auf, um die Treiberversion zu ermitteln. Wenn der Treiber ein ODBC 3.8-Treiber ist, können Sie treiberspezifische C-Typen verwenden. Verwenden Sie andernfalls keine treiberspezifischen C-Datentypen.
Beachten Sie, dass eine neu kompilierte ODBC 3.x-Anwendung andere ODBC 3.8-Features als treiberspezifische C-Typen verwenden kann, ohne SQL_OV_ODBC3_80 für SQL_ATTR_ODBC_VERSION anzugeben. Dies ähnelt einer neu kompilierten ODBC 2.x-Anwendung mit ODBC 3.x-Features.
Verwenden von SQLCancelHandle in einer Anwendung, die mit allen Treiber-Managern kompatibel ist
Da die SQLCancelHandle-Funktion in Treiber-Managern, die vor Windows 7 veröffentlicht wurden, nicht unterstützt wird, kann eine Anwendung nicht in älteren Versionen von Windows geladen werden, wenn sie SQLCancelHandle direkt aufruft. Um mit allen Versionen von Treibermanagern zu arbeiten und SQLCancelHandle in neuen Versionen von Windows zu verwenden, sollte eine Anwendung SQLCancelHandle indirekt mithilfe von LoadLibrary und GetProcAddress aufrufen.