3

SQLクエリを取得して実行し、結果セットのすべての列を行単位のバインディングを使用してSQL_C_WCHARとしてバインドするクラスがあります。

今私が行う方法は、char のベクトルを割り当て、次のように SQLBindColumn を与えるポインターを決定することです。

  • 列 1 のバッファ = &vec[0]
  • 列 1 の長さインジケータのバッファ = &vec[0] + (sizeof(SQLWCHAR) * 列 1 の長さ)
  • 列 2 のバッファ = &vec[0] + (sizeof(SQLWCHAR) * 列 1 の長さ) + sizeof(長さインジケータ)
  • 列 2 の長さ標識のバッファー = &vec[0] + (sizeof(SQLWCHAR) * 列 1 の長さ) + sizeof(長さ標識) + (sizeof(SQLWCHAR) * 列 2 の長さ)

等々

これにより、(SPARC で) アラインメントの問題が発生しています。パディングを追加する必要があることはわかっていますが、移植可能な量を計算する方法がわかりません。

4

2 に答える 2

2

私がそれを処理することになった方法は、実際に長さインジケーターとwcharを別々の正しく型指定されたバッファーに入れることでした。ODBCが行うのは、次のセットに移動するたびに各アドレスに「構造体サイズ」を追加することだけなので、実際には同じバッファに存在する必要はありません。

スタックに2つの小さな配列を割り当て、隣接するセル間のポインターを減算することにより、WCHARとSQLLENに必要な配置を理解しました。次に、両方の配置のLCMを取得し、各セットがそのスペースの倍数を占めるようにバッファーにパディングを追加しました。これを偽の「構造体サイズ」としてODBCにフィードしました。

于 2011-08-25T17:05:16.220 に答える
1

行単位のバインドは面倒です。ただし、インジケーター (StrLen_or_IndPtr 引数を意味すると仮定) は、SQLINTEGER/SQLLEN の別の配列で指定できると思いました (ODBC の新しさによって異なります)。SQL_DESC_INDICATOR_PTR のようなものを探してください。長さには別のものがあります。これらは、記述子でフィールドを設定することにより、データとは別に設定できます。これを行うと、アラインメントの問題を回避し、行データをインジケーター/長さとは別に保つことができます。

更新: http://msdn.microsoft.com/en-us/library/ms711730(v=vs.85).aspx

Update2:整数値(インジケータなど)が4バイト境界またはSparcが必要とするものに正しく配置されていることを確認してください。

于 2011-08-12T08:05:49.053 に答える