デスクトップ データベース ドライバー パフォーマンスの問題

既存の ANSI アプリケーションとの互換性を確保するために、SQL_WCHAR、SQL_WVARCHAR、およびSQL_WLONGVARCHARのデータ型は、Microsoft Access 4.0 以降のデータ ソースのSQL_CHAR、SQL_VARCHAR、およびSQL_LONGVARCHARとして公開されます。 データ ソースは WIDE CHAR データ型を返しませんが、データは引き続き Wide Char 形式で Jet に送信する必要があります。 SQL_C_CHAR パラメーターまたは結果列が ANSI アプリケーションのSQL_CHARデータ型にバインドされている場合、変換が行われることを理解しておくことが重要です。

この変換は、SQL_C_CHAR型が LONGVARCHAR 型のパラメーターにバインドされている場合、メモリの観点から特に非効率的な場合があります。 Jet 4.0 エンジンは LONGTEXT パラメーター データをストリーミングできないため、SQL_C_CHAR ANSI バッファーのサイズの 2 倍の UNICODE 変換バッファーを割り当てる必要があります。 最も効率的なメカニズムは、アプリケーションが UNICODE 変換を実行し、パラメーターを型SQL_C_WCHARとしてバインドすることです。 パラメーターが実行時データとしてマークされ、SQLPutData への複数の呼び出しでデータが指定されると、longtext データ バッファーが拡張されます。 この "Put Data" バッファーを拡張する費用を回避する方法の 1 つは、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 形式のデータベースに圧縮する必要があります。 これにより、2 つの Jet エンジンの読み込みがなくなり、データへのコード パスが最小限に抑えられます。

また、Jet 4.0 エンジンは Unicode エンジンです。 すべての文字列は Unicode で格納および操作されます。 ANSI アプリケーションが Jet 3 にアクセスする場合。Jet 4.0 エンジンを介して x データベースを使用すると、データは ANSI から Unicode に変換され、ANSI に戻されます。 データベースがバージョン 4.0 形式に更新された場合、文字列は Unicode に変換され、1 つのレベルの文字列変換が削除され、Jet エンジンを 1 つだけ通過してデータへのコード パスが最小限に抑えられます。