桌面数据库驱动程序性能问题

为了确保与现有 ANSI 应用程序的兼容性，SQL_WCHAR、SQL_WVARCHAR和SQL_WLONGVARCHAR数据类型公开为 Microsoft Access 4.0 或更高版本数据源的SQL_CHAR、SQL_VARCHAR和SQL_LONGVARCHAR。 数据源不返回 WIDE CHAR 数据类型，但仍必须以宽字符格式将数据发送到 Jet。 请务必了解，如果SQL_C_CHAR参数或结果列绑定到 ANSI 应用程序中的SQL_CHAR数据类型，转换将发生。

当SQL_C_CHAR类型绑定到 LONGVARCHAR 类型的参数时，这种转换在内存方面可能特别低效。 由于 Jet 4.0 引擎无法流式传输 LONGTEXT 参数数据，因此必须分配的 UNICODE 转换缓冲区的大小是SQL_C_CHAR ANSI 缓冲区大小的两倍。 最有效的机制是应用程序执行 UNICODE 转换并将参数作为类型绑定SQL_C_WCHAR。 当参数标记为执行时数据并在对 SQLPutData 的多次调用中提供数据时，将增加长文本数据缓冲区。 避免增加此“放置数据”缓冲区费用的一种方法是通过SQL_DATA_AT_EXEC_LEN (x) 提供可选长度，其中 x 是预期的字节长度。 这会将内部 PutData 缓冲区的大小初始化为 x 字节。

注意

可以使用 SQLBulkOperations () 或 SQLSetPos () 并将长数据设置为SQL_DATA_AT_EXEC，实现插入或更新长数据的有效方法。 在这种情况下，将忽略 (EXEC_LEN。) 数据可以通过多次调用 SQLPutData 以区块形式进行流式传输，这将有效地将数据追加到表中。

当通过 Microsoft ODBC 桌面数据库驱动程序使用 Jet 3.5 数据库的应用程序升级到版本 4.0 时，可能会出现性能下降和工作集大小增加的情况。 这是因为当版本 3。x 数据库是使用新版本 4.0 驱动程序打开的，它加载 Jet 4.0。 当 Jet 4.0 打开数据库时，发现数据库为 3。x 版本，它加载等效于加载 Jet 3.5 引擎的可安装 ISAM 驱动程序。 为了消除性能和大小损失，Jet 3。x 数据库应压缩为 Jet 4.0 格式数据库。 这将消除加载两个 Jet 引擎，并最大程度地减少数据的代码路径。

此外，Jet 4.0 引擎是 Unicode 引擎。 所有字符串都在 Unicode 中存储和操作。 ANSI 应用程序访问 Jet 3 时。x 数据库通过 Jet 4.0 引擎，数据从 ANSI 转换为 Unicode，然后转换回 ANSI。 如果数据库更新为版本 4.0 格式，则字符串将转换为 Unicode，删除一级字符串转换，并通过仅通过一个 Jet 引擎来最大程度地减少数据的代码路径。