Aktualisieren eines 3.5 Treibers auf einen 3.8-Treiber

Dieses Thema enthält Richtlinien und Überlegungen zum Upgrade eines ODBC 3.5-Treibers auf einen ODBC 3.8-Treiber.

Versionsnummern

Die folgenden Richtlinien beziehen sich auf Versionsnummern:

• Ein Treiber sollte SQL_OV_ODBC3_80 für SQL_ATTR_ODBC_VERSION unterstützen, SQL_ERROR für andere Werte als SQL_OV_ODBC2, SQL_OV_ODBC3 und SQL_OV_ODBC3_80 zurückgeben. In zukünftigen Versionen des Treiber-Managers wird davon ausgegangen, dass ein Treiber eine ODBC-Compliancestufe unterstützt, wenn der Treiber SQL_SUCCESS aus der SQLSetEnvAttr-Funktion zurückgibt.

• Ein Treiber der Version 3.8 sollte 03.80 von SQLGetInfo zurückgeben, wenn SQL_DRIVER_ODBC_VER an InfoType übergeben wird. Ältere Treibermanager, die in älteren Versionen von Microsoft Windows enthalten waren, behandeln den Treiber jedoch als Version 3.5-Treiber und geben eine Warnung aus.

  In Windows 7 ist die Treiber-Manager-Version 03.80. In Windows 8 ist die Treiber-Manager-Version 03.81 über die SQLGetInfo-SQL_DM_VER (InfoType-Parameter ). SQL_ODBC_VER meldet die Version als 03.80 in Windows 7 und Windows 8.

Treiberspezifische C-Datentypen

Ein Treiber kann angepasste C-Datentypen aufweisen, wenn er mit einer ODBC-Anwendung der Version 3.8 funktioniert. (Weitere Informationen finden Sie unter C-Datentypen in ODBC.) Es besteht jedoch keine Anforderung für einen 3.8-Treiber, um treiberspezifische C-Typen zu implementieren. Der Treiber sollte jedoch weiterhin die Bereichsprüfung von C-Typen durchführen; Der Treiber-Manager führt dies nicht für 3.8-Treiber aus. Um die Treiberentwicklung zu erleichtern, kann der Wert des treiberspezifischen C-Datentyps im folgenden Format definiert werden:

SQL_DRIVER_C_TYPE_BASE+0, SQL_DRIVER_C_TYPE_BASE+1  

Treiberspezifische Datentypen, Beschreibungstypen, Informationstypen, Diagnosetypen und Attribute

Beim Entwickeln eines neuen Treibers sollten Sie den treiberspezifischen Bereich für Datentypen, Deskriptortypen, Informationstypen, Diagnosetypen und Attribute verwenden. Treiberspezifische Bereiche und deren Basistypwerte werden in treiberspezifischen Datentypen, Deskriptortypen, Informationstypen, Diagnosetypen und Attributen erläutert.

Verbindungspooling

Für eine bessere Verwaltung von Verbindungspooling führt ODBC 3.8 das SQL_ATTR_RESET_CONNECTION Verbindungsattribut in SQLSetConnectAttr ein. SQL_RESET_CONNECTION_YES ist der einzige gültige Wert für dieses Attribut. SQL_ATTR_RESET_CONNECTION wird direkt vor dem Einfügen einer Verbindung vom Treiber-Manager in den Verbindungspool festgelegt, sodass der Treiber die anderen Verbindungsattribute auf ihre Standardwerte zurücksetzen kann.

Um unnötige Kommunikation mit dem Server zu vermeiden, kann ein Treiber das Verbindungsattribute zurückstellen, bis die nächste Kommunikation mit dem Remoteserver zurückgesetzt wird, nachdem die Verbindung aus dem Pool wiederverwendet wurde.

Beachten Sie, dass SQL_ATTR_RESET_CONNECTION nur in der Kommunikation zwischen dem Treiber-Manager und einem Treiber verwendet wird. Eine Anwendung kann dieses Attribut nicht direkt festlegen. Alle Version 3.8-Treiber sollten dieses Verbindungsattribut implementieren.

Streamed Output Parameters

ODBC Version 3.8 führt streamte Ausgabeparameter ein, eine skalierbarere Möglichkeit zum Abrufen von Ausgabeparametern. (Weitere Informationen finden Sie unter Abrufen von Ausgabeparametern mithilfe von SQLGetData.) Um dieses Feature zu unterstützen, sollte ein Treiber SQL_GD_OUTPUT_PARAMS im Rückgabewert festlegen, wenn SQL_GETDATA_EXTENSIONS der InfoType in einem SQLGetInfo-Aufruf ist. Die Unterstützung für einen SQL-Typ mit gestreamten Ausgabeparametern muss im Treiber implementiert werden. Der Treiber-Manager generiert keinen Fehler für einen ungültigen SQL-Typ. Die SQL-Typen, die gestreamte Ausgabeparameter unterstützen, werden im Treiber definiert.

Ein Treiber sollte SQL_ERROR zurückgeben, wenn die Anwendung SQLGetData zum Abrufen eines Parameters verwendet hat, der nicht mit dem von SQLParamData zurückgegebenen Parameter übereinstimmt.

Asynchrone Ausführung für Verbindungsvorgänge (Polling-Methode)

Ein Treiber kann asynchrone Unterstützung für verschiedene Verbindungsvorgänge aktivieren.

Ab Windows 7 unterstützt ODBC die Abrufmethode (weitere Informationen finden Sie unter asynchrone Ausführung (Polling-Methode). Für einen ODBC-Treiber der Version 3.8 ist es nicht erforderlich, asynchrone Vorgänge für Verbindungshandles zu implementieren. Auch wenn ein Treiber keine asynchronen Vorgänge für Verbindungshandles implementiert, sollte der Treiber weiterhin den SQL_ASYNC_DBC_FUNCTIONS InfoType implementieren und SQL_ASYNC_DBC_NOT_CAPABLE zurückgeben.

Wenn asynchrone Verbindungsvorgänge aktiviert sind, ist die Laufzeit eines Verbindungsvorgangs die Gesamtzeit aller wiederholten Aufrufe. Wenn der letzte wiederholte Aufruf erfolgt, nachdem die Gesamtzeit den vom SQL_ATTR_CONNECTION_TIMEOUT Verbindungsattribut festgelegten Wert überschritten hat und der Vorgang nicht abgeschlossen ist, gibt der Treiber SQL_ERROR zurück und protokolliert einen Diagnosedatensatz mit SQLState HYT01 und die Meldung "Verbindungstimeout abgelaufen". Es ist kein Timeout vorhanden, wenn der Vorgang abgeschlossen ist.

SQLCancelHandle-Funktion

ODBC 3.8 unterstützt die SQLCancelHandle-Funktion, die zum Abbrechen von Verbindungs- und Anweisungsvorgängen verwendet wird. Ein Treiber, der SQLCancelHandle unterstützt, muss die Funktion exportieren. Ein Treiber sollte keine synchrone oder asynchrone Verbindungsfunktion abbrechen, die ausgeführt wird, wenn die Anwendung SQLCancel oder SQLCancelHandle für ein Anweisungshandle aufruft. Ebenso sollte ein Treiber keine synchrone oder asynchrone Anweisungsfunktion abbrechen, die ausgeführt wird, wenn eine Anwendung SQLCancelHandle für das Verbindungshandle aufruft. Außerdem sollte ein Treiber den Browservorgang nicht abbrechen (SQLBrowseConnect gibt SQL_NEED_DATA zurück), wenn die Anwendung SQLCancelHandle für das Verbindungshandle aufruft. In diesen Fällen sollte ein Treiber HY010 zurückgeben, "Funktionssequenzfehler".

Es ist nicht erforderlich, sowohl SQLCancelHandle- als auch asynchrone Verbindungsvorgänge gleichzeitig zu unterstützen. Ein Treiber kann asynchrone Verbindungsvorgänge, aber nicht SQLCancelHandle oder umgekehrt unterstützen.

Angehaltene Verbindungen

Der ODBC 3.8-Treiber-Manager kann eine Verbindung in den angehaltenen Zustand versetzen. Eine Anwendung ruft SQLDisconnect auf, um ressourcen freizugeben, die der Verbindung zugeordnet sind. In diesem Fall sollte ein Treiber versuchen, so viele Ressourcen wie möglich freizugeben, ohne den Status der Verbindung zu überprüfen. Weitere Informationen zum angehaltenen Zustand finden Sie unter SQLEndTran Function.

Treiberfähiges Verbindungspooling

ODBC in Windows 8 ermöglicht Treibern das Anpassen des Verbindungspoolverhaltens. Weitere Informationen finden Sie unter Driver-Aware Connection Pooling.

Asynchrone Ausführung (Benachrichtigungsmethode)

ODBC 3.8 unterstützt die Benachrichtigungsmethode für asynchrone Vorgänge, die ab Windows 8 verfügbar sind. Weitere Informationen finden Sie unter Asynchrone Ausführung (Notification-Methode).For more information, see Asynchronous Execution (Notification Method).

Weitere Informationen

Developing an ODBC Driver (Entwickeln eines ODBC-Treibers)
Von Microsoft gelieferte ODBC-Treiber
What's New in ODBC 3.8 (Neues in ODBX 3.8)