Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Pour garantir la compatibilité avec les applications ANSI existantes, les SQL_WCHAR, les SQL_WVARCHAR et les types de données 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 de types de données WIDE CHAR, mais les données doivent toujours être envoyées à Jet sous forme 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 parvient pas à diffuser en continu les données des paramètres LONGTEXT, une mémoire tampon de conversion UNICODE doit être allouée deux fois la taille de la mémoire tampon ANSI SQL_C_CHAR. Le mécanisme le plus efficace est que l’application effectue la conversion UNICODE et lie le paramètre en tant que type SQL_C_WCHAR. Lorsqu’un paramètre est marqué comme étant des données en cours d’exécution et que les données sont fournies dans plusieurs appels à SQLPutData, une mémoire tampon de données longtexte est développée. Une façon d’éviter la croissance de cette mémoire tampon « Put Data » consiste à fournir une longueur facultative via SQL_DATA_AT_EXEC_LEN(x), où x correspond à la longueur attendue d’octets. Cela initialise la taille d’une mémoire tampon PutData interne sur x octets.
Remarque
Un moyen efficace d’insérer ou de mettre à jour des données longues peut être effectué à l’aide de SQLBulkOperations() ou de 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 efficacement les données à la table.
Lorsqu’une application utilisant une base de données Jet 3.5 via microsoft ODBC Desktop Database Drivers est mise à niveau vers la version 4.0, une dégradation des performances et une taille de jeu de travail accrue peut se produire. Cela est dû au fait qu’une version 3. x database est ouverte à l’aide du nouveau pilote version 4.0, elle charge Jet 4.0. Lorsque Jet 4.0 ouvre la base de données et voit que la base de données est une valeur 3. x version, il charge également un pilote ISAM installable équivalent au chargement du moteur Jet 3.5. Pour supprimer les performances et la pénalité 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 élimine le chargement de deux moteurs Jet et réduit 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. Lorsqu’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 retour en ANSI. Si la base de données est mise à jour au format version 4.0, les chaînes sont converties en Unicode, en supprimant un niveau de conversion de chaîne et en minimisant le chemin du code vers les données en passant par un seul moteur Jet.