Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Um die Kompatibilität mit vorhandenen ANSI-Anwendungen sicherzustellen, werden die Datentypen SQL_WCHAR, SQL_WVARCHAR und SQL_WLONGVARCHAR als SQL_CHAR, SQL_VARCHAR und SQL_LONGVARCHAR für Microsoft Access 4.0 oder höher verfügbar gemacht. Die Datenquellen geben keine WIDE CHAR-Datentypen zurück, aber die Daten müssen weiterhin im Wide Char-Formular an Jet gesendet werden. Es ist wichtig zu verstehen, dass die Konvertierung stattfindet, wenn ein SQL_C_CHAR Parameter oder eine Ergebnisspalte an einen SQL_CHAR Datentyp in einer ANSI-Anwendung gebunden ist.
Diese Konvertierung kann im Hinblick auf den Arbeitsspeicher besonders ineffizient sein, wenn ein SQL_C_CHAR Typ an einen Parameter vom Typ LONGVARCHAR gebunden ist. Da das Jet 4.0-Modul keine LONGTEXT-Parameterdaten streamen kann, muss ein UNICODE-Konvertierungspuffer zugeordnet werden, der doppelt so groß wie der SQL_C_CHAR ANSI-Puffer ist. Der effizienteste Mechanismus besteht darin, dass die Anwendung die UNICODE-Konvertierung durchführt und den Parameter als Typ SQL_C_WCHAR bindet. Wenn ein Parameter als "data-at-execution" gekennzeichnet ist und die Daten in mehreren Aufrufen von SQLPutData bereitgestellt werden, wird ein Longtext-Datenpuffer vergrößert. Eine Möglichkeit, die Kosten für das Wachstum dieses "Put Data"-Puffers zu vermeiden, besteht darin, eine optionale Länge über SQL_DATA_AT_EXEC_LEN(x) zu liefern, wobei x die erwartete Länge von Bytes ist. Dadurch wird die Größe eines internen PutData-Puffers in x Bytes initialisiert.
Hinweis
Eine effiziente Möglichkeit zum Einfügen oder Aktualisieren langer Daten kann mithilfe von SQLBulkOperations() oder SQLSetPos() erreicht werden und die langen Daten auf SQL_DATA_AT_EXEC festgelegt werden. (EXEC_LEN wird in diesem Fall ignoriert.) Daten können in Datenblöcken gestreamt werden, indem SQLPutData mehrmals aufgerufen wird, wodurch die Daten effektiv an die Tabelle angefügt werden.
Wenn eine Anwendung, die eine Jet 3.5-Datenbank über die Microsoft ODBC-Desktopdatenbanktreiber verwendet, auf Version 4.0 aktualisiert wird, kann eine Leistungsbeeinträchtigung und eine erhöhte Arbeitssatzgröße auftreten. Dies liegt daran, dass eine Version 3. Die x-Datenbank wird mit dem neuen Treiber der Version 4.0 geöffnet und lädt Jet 4.0. Wenn Jet 4.0 die Datenbank öffnet und sieht, dass die Datenbank ein 3 ist. x-Version lädt einen installierbaren ISAM-Treiber, der dem Laden des Jet 3.5-Moduls entspricht. Um die Leistung und Größenstrafe zu entfernen, ist Jet 3. x-Datenbank sollte in eine Jet 4.0-Formatdatenbank komprimiert werden. Dadurch werden das Laden von zwei Jet-Engines eliminiert und der Codepfad zu den Daten minimiert.
Außerdem ist das Jet 4.0-Modul ein Unicode-Modul. Alle Zeichenfolgen werden in Unicode gespeichert und bearbeitet. Wenn eine ANSI-Anwendung auf einen Jet 3 zugreift. x-Datenbank über das Jet 4.0-Modul, die Daten werden von ANSI in Unicode und zurück in ANSI konvertiert. Wenn die Datenbank auf das Version 4.0-Format aktualisiert wird, werden die Zeichenfolgen in Unicode konvertiert, wobei eine Ebene der Zeichenfolgenkonvertierung entfernt und der Codepfad zu den Daten minimiert wird, indem nur ein Jet-Modul durchlaufen wird.