Leistungsprobleme bei Desktop-Datenbanktreibern

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 Format Wide Char an Jet gesendet werden. Es ist wichtig zu verstehen, dass die Konvertierung erfolgt, 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 die Jet 4.0-Engine keine LONGTEXT-Parameterdaten streamen kann, muss ein UNICODE-Konvertierungspuffer zugewiesen werden, der doppelt so groß ist wie der SQL_C_CHAR ANSI-Puffers. 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 Datenausführung gekennzeichnet ist und die Daten in mehreren Aufrufen von SQLPutData bereitgestellt werden, wird ein Longtextdatenpuffer vergrößert. Eine Möglichkeit, den Aufwand für das Erweitern dieses Puffers "Put Data" zu vermeiden, besteht darin, eine optionale Länge über SQL_DATA_AT_EXEC_LEN(x) zur Verfügung zu stellen, wobei x die erwartete Länge von Bytes ist. Dadurch wird die Größe eines internen PutData-Puffers auf x Bytes initialisiert.

Wenn eine Anwendung, die eine Jet 3.5-Datenbank über die Microsoft ODBC Desktop-Datenbanktreiber verwendet, auf Version 4.0 aktualisiert wird, können leistungseinbußen und eine erhöhte Arbeitssatzgröße auftreten. Dies liegt daran, wenn 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 erkennt, dass die Datenbank eine 3 ist. x-Version lädt einen installierbaren ISAM-Treiber, der dem Laden der Jet 3.5-Engine entspricht. Um die Leistungs- und Größenstrafe zu entfernen, wird der Jet 3 verwendet. x-Datenbank sollte in eine Datenbank im Jet 4.0-Format komprimiert werden. Dadurch wird das Laden von zwei Jet-Engines eliminiert und der Codepfad zu den Daten minimiert.

Außerdem ist die Jet 4.0-Engine eine Unicode-Engine. Alle Zeichenfolgen werden in Unicode gespeichert und bearbeitet. Wenn eine ANSI-Anwendung auf einen Jet 3 zugreift. x-Datenbank über die Jet 4.0-Engine, die Daten werden von ANSI in Unicode und zurück in ANSI konvertiert. Wenn die Datenbank auf das Format der Version 4.0 aktualisiert wird, werden die Zeichenfolgen in Unicode konvertiert, wodurch eine Ebene der Zeichenfolgenkonvertierung entfernt wird und der Codepfad zu den Daten minimiert wird, indem nur eine Jet-Engine durchlaufen wird.