次の方法で共有


文字データと C 文字列

可変長文字データ (列名、動的パラメーター、文字列属性値など) を参照する入力パラメーターには、長さパラメーターが関連付けられています。 C で一般的なとおり、アプリケーションが null 文字で文字列を終了する場合は、文字列の長さ (null 終端を含まない) またはSQL_NTS (Null 終端文字列) のいずれかを引数として提供します。 負以外の長さの引数は、関連付けられた文字列の実際の長さを指定します。 長さ 0 の文字列を指定する場合は、長さ引数 0 を指定できます。これは NULL 値とは異なります。 負の値 SQL_NTS は、null 終端文字を見つけることによって文字列の長さを決定するドライバーを指示します。

ドライバーからアプリケーションに文字データが返される場合、ドライバーは常に null で終端する必要があります。 これにより、データを文字列として処理するか、文字配列として処理するかをアプリケーションで選択できます。 アプリケーション バッファーがすべての文字データを返すのに十分な大きさでない場合、ドライバーはバッファーのバイト長まで切り捨て、null 終端文字に必要なバイト数を減らし、null で切り捨てられたデータを終了し、バッファーに格納します。 そのため、アプリケーションでは、文字データの取得に使用されるバッファー内の null 終端文字に対して、常に余分な領域を割り当てる必要があります。 たとえば、50 文字のデータを取得するには、51 バイトのバッファーが必要です。

SQLPutData または SQLGetData を使用してパーツ内の長い文字データを送信または取得する場合は、アプリケーションとドライバーの両方で特別な注意を払う必要があります。 データが一連の null で終端する文字列として渡される場合は、データを再構築する前に、これらの文字列の null 終端文字を削除する必要があります。

多くの ODBC プログラマが、文字データと C 文字列を混同しています。 これが発生したのが、ODBC 関数を定義するときに C 言語を使用するというアーティファクトです。 ODBC ドライバーまたはアプリケーションが別の言語を使用している場合は、ODBC が言語に依存しない点に注意してください。この混乱は発生する可能性が低くなります。

文字データを保持するために C 文字列を使用する場合、null 終端文字はデータの一部とは見なされず、バイト長の一部としてカウントされません。 たとえば、文字データ「ABC」は、C 文字列「ABC\0」または文字配列 {'A', 'B', 'C'} として保持できます。 データのバイト長は、文字列または文字配列として扱われるかどうかに関係なく、3 です。

アプリケーションとドライバーでは通常、文字データを保持するために C 文字列 (null で終端する文字の配列) が使用されますが、これを行う必要はありません。 C では、文字データは文字の配列 (null 終端なし) と、長さ/インジケーター バッファーで個別に渡されるバイト長として扱うこともできます。

文字データは null で終わる非配列に保持でき、そのバイト長は個別に渡されるため、文字データに null 文字を埋め込むことができます。 ただし、この場合の ODBC 関数の動作は未定義であり、ドライバーがこれを正しく処理するかどうかはドライバー固有です。 したがって、相互運用可能なアプリケーションでは、埋め込み null 文字をバイナリ データとして含めることができる文字データを常に処理する必要があります。