6.1.1　SQLの記述形式

(a)　データベース中の文字コードをEBCDIK/KEISにする場合

(i)データ長の変化

KEISコードは，半角の文字（1バイトの文字）と全角の文字（2バイトの文字）を区別するために，シフトコードという制御コードを用います。シフトコードはデータ表示時には表示されませんが，データとして存在するため，見かけの文字長と実際のデータ長が異なります。一方，シフトJISと日本語EUCでは，シフトコードのような制御コードを持ちません。このため，文字コード変換によってデータの長さが変化する場合があります。

次に例を示します。

なお，ここではKEISコードへシフトするシフトコードを[漢]，EBCDIKコードへシフトするシフトコードを[E]と表します。[漢]は0x0A42，[E]は0x0A41という2バイトのデータです。

ケース	シフトJISまたは日本語EUCでのデータ	EBCDIK/KEISでのデータ
半角文字だけの場合 （VARCHAR型）	'ABCD' （4バイト）	'ABCD' （4バイト）
全角文字だけの場合 （NVARCHAR型）	'あいう' （6バイト）	'あいう' （6バイト）
半角文字と全角文字が混在する場合 （MVARCHAR型）	'AあBいC' （7バイト）	'A[漢]あ[E]B[漢]い[E]C' （15バイト）

半角文字と全角文字が混在するデータの場合，シフトJISまたは日本語EUCのデータをEBCDIK/KEISに変換すると，最大7/3倍になります。

このため，混在文字データを扱う場合のシステムでは次のようにします。

• 表定義時の列の長さ

  シフトJISまたは日本語EUCのデータ長の7/3倍以上で定義してください。

（例）

UAPで100バイトの混在文字データを扱う場合，列の定義はMVARCHAR（100）ではなく，MVARCHAR（234）で定義します。

• UAPで使用する埋込み変数

  ある表のデータの追加・更新をXDM/RD E2接続機能だけを使用して行う場合は，その表にアクセスするSQLの埋込み変数を，その埋込み変数に対応する列の定義長の3/7倍の長さで定義してください。

（例1）

「表定義時の列の長さ」の例の列に対してデータを挿入（INSERT）する場合の埋込み変数は，MVARCHAR（100）に対応する埋込み変数の定義をしてください。

C言語の場合は，次のようになります。

struct {
 short  変数名1 ;
 char   変数名2[100] ;
} 構造体名 :

なお，可変長の場合は，実長（変数名1で示す長さ）が100バイト以下であれば，変数名2の長さは100バイトを超えていてもかまいません。また，EBCDIK/KEISに変換しても234バイト以下となるデータであれば，実長が100バイトを超えていてもかまいません。

しかし，シフトJISまたは日本語EUCで100バイトを超えるデータをデータベースに格納すると，検索時に100バイトの埋込み変数で受け取れなくなる場合があります。これを防止するため，挿入データに対応する埋込み変数の定義長は，100バイトにしておくことをお勧めします。

（例2）

「表定義時の列の長さ」の例の列を検索（FETCH）する場合の埋込み変数は，MVARCHAR（100）に対応する埋込み変数の定義をしてください。

ただし，これはデータベース中に格納されているすべてのEBCDIK/KEISのデータが，シフトJISまたは日本語EUCに変換しても100バイト以下のデータである場合に限ります。

ある表のデータの追加・更新をXDM/RD E2接続機能以外の方法で行うことがある場合は，その表にアクセスするSQLの埋込み変数の長さは次のとおりにしてください。

対象列	処理	MVARCHAR型変数の長さ
		シフトJISの場合	日本語EUCの場合
MCHAR(n)および MVARCHAR(n)	検索	定義長=n	定義長=n×2
	格納	実長≦n×(3/7)※	実長≦n×(3/7)※

注※　

追加・更新するデータのEBCDIK/KEISでのバイト数がわからない場合の見積もりです。バイト数がわかる場合は，EBCDIK/KEISでのバイト数≦nになるようにしてください。

（例3）

HiRDBクライアント以外を使用してデータの追加・更新を行うことがある表にMVARCHAR（100）の列が存在する場合は，この列を検索（FETCH）するときの埋込み変数は，3/7倍にするのではなく，次のようにしてください。

• クライアントの文字コードがシフトJISの場合

  MVARCHAR（100）に対応する埋込み変数の宣言としてください。これは，既存のデータベース中に1バイト文字だけ格納されている場合があるためです。

• クライアントの文字コードが日本語EUCの場合

  MVARCHAR(200)に対応する埋込み変数の宣言としてください。これは，既存のデータベース中に半角カタカナ文字だけ格納されている場合があるためです。半角カタカナはEBCDIK/KEISでは１文字が１バイトですが，日本語EUCでは1文字が２バイトになるので，EBCDIK/KEISのデータを日本語EUCに変換すると，最大２倍になります。

(ii)固定長文字に対する考慮

全角文字を含むシフトJISまたは日本語EUCのデータをEBCDIK/KEISに変換すると，データ長が変化するため，全角文字を扱う場合は，固定長データ（MCHAR）ではなく可変長データ（MVARCHAR）とすることをお勧めします。

固定長データ（MCHAR）とする場合には，次の点に注意してください。

• 文字長の変化

  (i)と同様に，挿入（INSERT）時などに使用する埋込み変数は，対応するデータの3/7倍にします。

  代入先のデータ長が代入元より短い場合は，代入先に空白が補われます。

  埋込み変数が3/7倍以上の場合は，次のような事象が発生します。

（例）

C言語の埋込み型UAPであり，表の列の定義がMCHAR（234）の場合で，「INSERT INTO 表 VALUES（：埋込み変数）」としたときの結果を次に示します。

なお，'△'は半角の空白1文字を示し，'\0'はC言語のナル文字を示します。

埋込み変数の型 （C言語の場合）	埋込み変数のデータ	結果
char 変数名[235];	'ABCDEFG△△…△\0' （空白は228個）	左記データが正しく格納される。
	'あいうえお△△…△\0' （空白は224個）	SQLCODE=-404エラー※
char 変数名[101];	'あいうえお△△…△\0' （空白は90個）	左記データが正しく格納される。

注※

'あいうえお△△…△'（空白は224個）をEBCDIK/KEISに変換すると，'[漢]あいうえお[E]△△…△'（空白は224個）となり，長さが238バイトになります。その結果，挿入するデータ長が列の定義長を超えるため，エラーになります。

• LIKE述語の比較

  XDM/RD E2の固定長文字列に対する比較述語では，長さが異なるデータを比較する場合は，短い方に空白を補って比較します。しかし，LIKE述語に関しては空白を補いません。

  このため，LIKE述語でパターン文字'％'（0文字以上の任意の文字）を使用しない場合は，比較するときに意図する検索ができない場合があります。

（例）

表の列の型がMCHAR（234）であり，かつ格納されているデータが'ABCDEFG△△…△'と'あいうえお△△…△'である場合で，SELECT文の探索条件を「WHERE 値式 LIKE ：埋込み変数」としたときの結果を次に示します。

なお，'△'は半角の空白1文字を示し，'\0'はC言語のナル文字を示します。

埋込み変数の型 （C言語の場合）	埋込み変数のデータ	「WHERE 値式 LIKE ：埋込み変数」 の評価
char 変数名[235];	'ABCDEFG△△…△\0' （空白は228個）	真
	'ABCDEFG\0'	偽※1
	'あいうえお△△…△\0' （空白は224個）	偽
	'あいうえお△△…△\0' （空白は220個）	真※2
char 変数名[101];	'ABCDEFG△△…△\0' （空白は93個）	偽
	'ABCDEFG\0'	偽
	'あいうえお△△…△\0' （空白は90個）	偽

注※1

UAPがC言語で記述されている場合，データ中に'\0'が含まれていると，データ長を'\0'の一つ前までの長さとみなします。このため，「長さ7バイトのデータ'ABCDEFG'」とデータベースの「長さ234バイトのデータ'ABCDEFG△△△'」を比較します。

'%'を含まないLIKE述語は，長さが一致しなければ真とはならないため，この評価は「偽」となります。

注※2

半角文字だけを扱う場合は，埋込み変数に対応するSQLのデータ型のデータ長と同じ長さで埋込み変数を定義して，'％'を含まないLIKE述語を「真」にできます。

しかし，全角文字が含まれる場合は，EBCDIK/KEISに変換した後のデータ長を考慮したデータ長としなければなりません。

この例では，[漢]と[E]が付加されて4バイト大きくなるため，定義長（234バイト）よりも4バイト少なくなる位置に'\0'を埋め込みます。

(iii)空白の扱い

空白には半角の空白と全角の空白があります。XDM/RD E2には，空白に関する変換規則について次に示すオプションがあります。このオプションは，XDM/RD E2のRD環境定義文で指定します。詳細については，マニュアル「VOS3 データマネジメントシステム　XDM E2系　XDM/RD E2 使用の手引−RD環境定義文・空間起動制御文・運用コマンド編−」を参照してください。

HALFSPACE

XDM/RD E2のRD環境定義文のCONVERT OPTION句にHALFSPACE HALFを指定することをお勧めします。

HALFSPACE HALFを指定すると，半角空白が2文字連続した場合の文字コードが次のように変換されます。

変換方向	変換前データ	変換後データ
		HALFSPACE HALFを指定	HALFSPACEを省略
シフトJISまたは日本語EUC→ EBCDIK/KEIS	半角空白2文字 （0x2020）	半角空白2文字 （0x4040）	半角空白2文字 （0x4040）
EBCDIK/KEIS→ シフトJISまたは日本語EUC	半角空白2文字 （0x4040）	半角空白2文字 （0x2020）	全角空白1文字 （0x8140）

HALFSPACE HALFを指定することで，クライアント側から挿入した半角空白2文字を検索する場合，挿入した値を同じ値で検索できます。

(iv)EUCコードセット３の外字の扱い

ここでは，クライアントの文字コードが日本語EUCの場合の，EUCコードセット３の外字の扱いについて説明します。

EUCコードセット３の外字を含むデータを，NCHARおよびNVARCHAR型の変数に格納すると正しく処理されません。これは，NCHARおよびNVARCHAR型の変数はデータ長をバイト数ではなく文字数で指定し，１文字が２バイトであることを前提にして処理されているためです。EUCコードセット３の外字は１文字が３バイトなので，正しく処理されません。

（例１）

EUCコードセット３の外字コードを含むNCHARおよびNVARCHAR型の列を対象に検索，格納，比較を行う場合は，VARCHAR型またはCHAR型の変数を使用してください。EUCコードセット１の漢字（１文字が２バイト）とEUCコードセット３の外字が混在すると，文字数からデータのバイト数が確定しないので，NCHAR型（固定長）の列が対象の場合でもVARCHAR型（可変長）の変数を使用することをお勧めします。変数の長さは次のようになります。

対象列	処理	VARCHAR型変数の長さ
NCHAR(n)および NVACHAR(n)	検索	定義長(バイト数)=n×3
	格納	実長≦n×2※

注※　格納するデータの文字数がわからない場合の計算です。文字数がわかる場合は，文字数≦nにしてください。

（例２）

DESCRIBE文がSQL記述領域に設定したデータ型がNCHARおよびNVARCHAR型の場合に，EUCコードセット３の外字を含むデータを変数に格納するときは，SQL記述領域のデータ型をVARCHAR型に書き換えてください。

(b)　データベース中の文字コードをシフトJISにする場合

CREATE TABLE文で表を定義する場合に，文字集合の指定でシフトJISを選択すると，データベースに格納する文字コードがシフトJISになります。

データベース中のデータがシフトJISの場合，文字コードを変換する必要がなくなるため，「(a) データベース中の文字コードをEBCDIK/KEISにする場合」の注意事項を考慮する必要がありません。

文字集合としてシフトJISを使用する場合のCREATE TABLE文の例を次に示します。

CREATE TABLE 表名 （列名 CHAR（100） CHARACTER SET SHIFT_JIS）

なお，文字集合をシフトJISにする場合は，次の点に注意してください。

(i)VOS3上のUAPでの文字コード変換

WSやPCで動作するHiRDBクライアントのUAPでは文字コードを変換する必要がありませんが，VOS3上で動作するUAP（EBCDIK/KEISを使用するUAP）では文字コードを変換する必要があります。

このため，VOS3上のUAPを作成する上で，文字コードを変換するときに注意する必要があります。

(ii)制限事項

XDM/RD E2側で文字集合とほかの機能の組み合わせが制限されている場合があります。次にXDM/RD E2 07-00での制限事項の一部を示します。その他の制限事項については，XDM/RD E2のマニュアルを参照してください。

• 文字集合シフトJISの列を分割表の分割条件列に指定できない。

• 文字集合シフトJISの列をインデクス除外値構成列に指定できない。