Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Чтобы обеспечить совместимость с существующими приложениями ANSI, SQL_WCHAR, SQL_WVARCHAR и SQL_WLONGVARCHAR типы данных предоставляются как SQL_CHAR, SQL_VARCHAR и SQL_LONGVARCHAR для источников данных Microsoft Access 4.0 или более поздних версий. Источники данных не возвращают типы данных WIDE CHAR, но данные по-прежнему должны отправляться в Jet в формате Wide Char. Важно понимать, что преобразование произойдет, если параметр SQL_C_CHAR или результирующий столбец привязан к типу данных SQL_CHAR в приложении ANSI.
Это преобразование может быть особенно неэффективным с точки зрения памяти, если тип SQL_C_CHAR привязан к параметру типа LONGVARCHAR. Так как подсистема Jet 4.0 не может передавать данные параметров LONGTEXT, буфер преобразования ЮНИКОД должен быть выделен в два раза больше, чем буфер ANSI SQL_C_CHAR. Наиболее эффективным механизмом является выполнение преобразования ЮНИКОДа и привязка параметра к типу SQL_C_WCHAR. Если параметр помечается как данные при выполнении и данные предоставляются в нескольких вызовах SQLPutData, буфер данных longtext растет. Одним из способов избежать расходов на увеличение этого буфера Put Data является предоставление необязательной длины через SQL_DATA_AT_EXEC_LEN(x), где x является ожидаемой длиной байтов. Это инициализирует размер внутреннего буфера PutData до x байтов.
Замечание
Эффективный способ вставки или обновления длинных данных можно выполнить с помощью SQLBulkOperations() или SQLSetPos() и настройки длинных данных для SQL_DATA_AT_EXEC. (в данном случае EXEC_LEN игнорируется.) Данные можно передавать в блоки, вызывая SQLPutData несколько раз, что эффективно добавляет данные в таблицу.
При обновлении приложений с базой данных Jet 3.5 с помощью драйверов классических баз данных Microsoft ODBC до версии 4.0 может произойти снижение производительности и увеличение размера рабочего набора. Это связано с тем, что в версии 3. База данных x открыта с помощью нового драйвера версии 4.0, она загружает Jet 4.0. Когда Jet 4.0 открывает базу данных и видит, что база данных является 3. X версия, она загружает устанавливаемый драйвер ISAM, эквивалентный загрузке двигателя Jet 3.5, а также. Чтобы удалить штраф производительности и размера, Jet 3. База данных x должна быть компактирована в базу данных формата Jet 4.0. Это позволит исключить загрузку двух обработчиков Jet и свести к минимуму путь кода к данным.
Кроме того, двигатель Jet 4.0 является двигателем Юникода. Все строки хранятся и управляются в Юникоде. Когда приложение ANSI обращается к Jet 3. База данных x через подсистему Jet 4.0 данные преобразуются из ANSI в Юникод и обратно в ANSI. Если база данных обновляется до формата 4.0, строки преобразуются в Юникод, удаляя один уровень преобразования строк, а также минимизируя путь кода к данным, проходя только один обработчик Jet.