Partage via

Problèmes de performances des pilotes pour les bases de données de poste de travail

  • Article

Pour garantir la compatibilité avec les applications ANSI existantes, les types de données SQL_WCHAR, SQL_WVARCHAR et SQL_WLONGVARCHAR sont exposés en tant que SQL_CHAR, SQL_VARCHAR et SQL_LONGVARCHAR pour les sources de données Microsoft Access 4.0 ou ultérieures. Les sources de données ne retournent pas les types de données WIDE CHAR, mais les données doivent toujours être envoyées à Jet au format Wide Char. Il est important de comprendre que la conversion aura lieu si un paramètre SQL_C_CHAR ou une colonne de résultat est lié à un type de données SQL_CHAR dans une application ANSI.

Cette conversion peut être particulièrement inefficace en termes de mémoire lorsqu’un type SQL_C_CHAR est lié à un paramètre de type LONGVARCHAR. Étant donné que le moteur Jet 4.0 ne peut pas diffuser en continu les données des paramètres LONGTEXT, une mémoire tampon de conversion UNICODE doit être allouée qui est deux fois plus grande que la SQL_C_CHAR mémoire tampon ANSI. Le mécanisme le plus efficace consiste pour l’application à effectuer la conversion UNICODE et à lier le paramètre comme type SQL_C_WCHAR. Lorsqu’un paramètre est marqué comme data-at-execution et que les données sont fournies dans plusieurs appels à SQLPutData, une mémoire tampon de données de texte long est développée. Une façon d’éviter les dépenses liées à la croissance de cette mémoire tampon « Put Data » consiste à fournir une longueur facultative via SQL_DATA_AT_EXEC_LEN(x), où x est la longueur attendue des octets. Cela initialise la taille d’une mémoire tampon PutData interne à x octets.

Notes

Un moyen efficace d’insérer ou de mettre à jour des données longues peut être effectué à l’aide de SQLBulkOperations() ou SQLSetPos() et de définir les données longues sur SQL_DATA_AT_EXEC. (EXEC_LEN est ignoré dans ce cas.) Les données peuvent être diffusées en blocs en appelant SQLPutData plusieurs fois, ce qui ajoute effectivement les données à la table.

Lorsqu’une application utilisant une base de données Jet 3.5 via les pilotes de base de données de bureau Microsoft ODBC est mise à niveau vers la version 4.0, une dégradation des performances et une taille de groupe de travail accrue peuvent se produire. Cela est dû au fait qu’une version 3. La base de données x est ouverte à l’aide du nouveau pilote version 4.0, elle charge Jet 4.0. Quand Jet 4.0 ouvre la base de données et voit que la base de données est un 3. x version, il charge un pilote ISAM installable qui équivaut également à charger le moteur Jet 3.5. Pour supprimer la pénalité de performances et de taille, jet 3. La base de données x doit être compactée dans une base de données au format Jet 4.0. Cela permet d’éliminer le chargement de deux moteurs Jet et de réduire le chemin du code vers les données.

En outre, le moteur Jet 4.0 est un moteur Unicode. Toutes les chaînes sont stockées et manipulées dans Unicode. Quand une application ANSI accède à un Jet 3. x base de données via le moteur Jet 4.0, les données sont converties d’ANSI en Unicode et de nouveau en ANSI. Si la base de données est mise à jour au format 4.0, les chaînes sont converties en Unicode, ce qui supprime un niveau de conversion de chaîne et réduit le chemin du code vers les données en passant par un seul moteur Jet.