次の表は、SQL Anywhere および Ultra Light のリモートデータ型がどのように IBM DB2 LUW の統合データ型にマッピングされるのかを示します。たとえば、リモートデータベースの BIT 型のカラムは、統合データベースでは SMALLINT 型である必要があります。
IBM DB2 LUW テーブルを作成する場合は、DB2 のページサイズに注意する必要があります。IBM DB2 LUW には、ページサイズに基づく最大ロー長 (MRL) があります。ページサイズが 4K の場合の MRL は 4005 です。8K の場合は 8101、16K の場合は 16293、32K の場合は 32677 になります。テーブルに含まれる全カラムの長さがこの制限を超えることはできません。テーブルに BLOB または CLOB カラムがある場合は、BLOB または CLOB データを直接カウントするのではなく、LOB ロケータを使用してロー長をカウントできます。詳細については、IBM DB2 LUW のマニュアルを参照してください。
SQL Anywhere または Ultra Light のデータ型 | IBM DB2 LUW のデータ型 | 説明 |
---|---|---|
BIGINT |
BIGINT |
|
BINARY(n<MRL) |
VARCHAR(n) FOR BIT DATA |
|
BINARY(n>=MRL) |
BLOB(n) |
|
BIT |
SMALLINT |
|
CHAR(n<MRL) |
VARCHAR(n) |
|
CHAR(n>=MRL) |
CLOB(n) |
IBM DB2 LUW の値が SQL Anywhere または Ultra Light の値より長い可能性があるので、ダウンロード時には値が大きすぎないことを確認してください。 |
DATE |
DATE |
SQL Anywhere と Ultra Light では、時刻の値は 00:00:00 の形式である必要があります。 |
DATETIME |
TIMESTAMP |
|
DECIMAL(p<32,s) |
DECIMAL(p,s) |
SQL Anywhere の DECIMAL の精度は 1 ~ 127 です。IBM DB2 LUW DECIMAL の最大精度は 31 です。 |
DECIMAL(p>=32,s) |
SQL Anywhere の DECIMAL で精度が 31 より大きいデータは、IBM DB2 LUW に同期できません。 |
|
DOUBLE |
DOUBLE |
DOUBLE は、丸め誤差が出る可能性がある概数値データ型です。種類の異なるコンピューターを使用すると、DOUBLE の基本となる記憶領域が異なることが多く、したがって、丸めの結果も異なります。プライマリキーは等しいかどうかの確認に使用されるので、プライマリキーで DOUBLE を使用することはおすすめできません。これは特に同期環境で言えます。特に、統合データベースはリモートデータベースとは異なるハードウェアで実行されることが多いからです。 |
FLOAT(1-24) |
REAL |
FLOAT はあいまいな値なので、統合データベースとリモートデータベースとで厳密に同じ値を使用できない場合、問題を引き起こすことがあります。取り得るすべての値がテスト済みであるわけではないので、注意が必要です。問題の発生を回避するため、このような型をプライマリキーの一部として使用しないでください。 |
FLOAT(25-53) |
DOUBLE |
FLOAT はあいまいな値なので、統合データベースとリモートデータベースとで厳密に同じ値を使用できない場合、問題を引き起こすことがあります。取り得るすべての値がテスト済みであるわけではないので、注意が必要です。問題の発生を回避するため、このような型をプライマリキーの一部として使用しないでください。 |
IMAGE |
BLOB(n) |
|
INTEGER |
INTEGER |
|
LONG BINARY |
BLOB(n) |
|
LONG NVARCHAR |
CLOB(n) |
IBM DB2 LUW には対応するデータ型がありません。IBM DB2 LUW の文字セットがユニコードの場合は、SQL Anywhere の LONG NVARCHAR を DB2 の CLOB に同期できます。Ultra Light には LONG NVARCHAR はありません。 |
LONG VARBIT |
CLOB(n) |
|
LONG VARCHAR |
CLOB(n) |
|
MONEY |
DECIMAL(19,4) |
|
NCHAR(c) |
VARCHAR(n) または CLOB(n) |
IBM DB2 LUW には対応するデータ型がありません。IBM DB2 LUW の文字セットが Unicode の場合は、NCHAR を IBM DB2 LUW の VARCHAR または CLOB に同期できます。SQL Anywhere の NCHAR のサイズは文字単位で、IBM DB2 LUW の VARCHAR のサイズはバイト単位です。VARCHAR にマッピングする場合は、NCHAR のバイト数の合計が MRL より大きくならないようにしてください。そのようにできない場合、NCHAR は CLOB にマッピングします。NCHAR(c) のバイト数の計算は簡単ではありませんが、おおよそ c=n/4 です。一般的には、c が MRL/4 より小さい場合は VARCHAR(n) にマッピングし、c が MRL/4 以上の場合は CLOB(n) にマッピングします。 |
NUMERIC(p<32,s) |
NUMERIC(p,s) |
|
NUMERIC(p>=32,s) |
IBM DB2 LUW には対応するデータ型がありません。 |
|
NTEXT |
CLOB(n) |
IBM DB2 LUW には対応するデータ型がありません。IBM DB2 LUW の文字セットが Unicode の場合は、NTEXT を IBM DB2 LUW CLOB に同期できます。 |
NVARCHAR(c) |
VARCHAR(n) または CLOB(n) |
IBM DB2 LUW には対応するデータ型がありません。IBM DB2 LUW の文字セットが Unicode の場合は、NVARCHAR を IBM DB2 LUW の VARCHAR または CLOB に同期できます。SQL Anywhere の NVARCHAR のサイズは文字単位で、IBM DB2 LUW の VARCHAR のサイズはバイト単位です。VARCHAR にマッピングする場合は、NVARCHAR のバイト数の合計が MRL より大きくならないようにしてください。そのようにできない場合、NVARCHAR は CLOB にマッピングします。NVARCHAR(c) のバイト数の計算は簡単ではありませんが、おおよそ c=n/4 です。一般的には、c が MRL/4 より小さい場合は VARCHAR(n) にマッピングし、c が MRL/4 以上の場合は CLOB(n) にマッピングします。 |
REAL |
REAL |
REAL はあいまいな値なので、統合データベースとリモートデータベースとで厳密に同じ値を使用できない場合、問題を引き起こすことがあります。取り得るすべての値がテスト済みであるわけではないので、注意が必要です。問題の発生を回避するため、このような型をプライマリキーの一部として使用しないでください。 |
SMALLDATETIME |
TIMESTAMP |
|
SMALLINT |
SMALLINT |
|
SMALLMONEY |
DECIMAL(10,4) |
|
ST_GEOMETRY |
ST_GEOMETRY |
|
TEXT |
CLOB(n) |
|
TIME |
TIMESTAMP または TIME |
小数点以下の秒がある SQL Anywhere と Ultra Light の TIME 値には、IBM DB2 LUW の TIMESTAMP が必要です。小数点以下の秒が常に 0 の SQL Anywhere と Ultra Light の TIME 値には、IBM DB2 の TIME を使用できます。時刻カラムの精度を保持するため、Mobile Link サーバーでは、TIME カラムが常に ODBC SQL_TYPE_TIMESTAMP データ型にバインドされます。統合データベースが DB2 9.7 サーバーで実行されているときは、カラムがプライマリキーの一部である場合、DB2 変換関数を使用してカラムを TIMESTAMP と TIME の間で明示的に変換する必要があります。 |
TIMESTAMP |
TIMESTAMP |
|
TIMESTAMP WITH TIME ZONE | VARCHAR(34) | IBM DB2 LUW には対応するデータ型がありません。したがって、TIMESTAMP WITH TIME ZONE カラムを VARCHAR(34) カラムにマッピングする必要があります。アップロード時、Mobile Link サーバーは、まずデータを YYYY-MM-DD HH:NN:SS.SSSSSS [+|-]HH:NN フォーマットの文字列に変換してから統合データベースに適用します。ダウンロード時は、データを文字列から TIMESTAMP WITH TIME ZONE に変換します。統合データベース内のデータがこのフォーマットに従っていない場合は、ダウンロードが失敗します。 |
TINYINT |
SMALLINT |
ダウンロードの場合、IBM DB2 LUW の値は負でない必要があります。 |
UNIQUEIDENTIFIER |
CHAR(36) |
|
UNIQUEIDENTIFIERSTR |
CHAR(36) |
UNIQUEIDENTIFIERSTR の IBM DB2 LUW での使用はおすすめしません。代わりに UNIQUEIDENTIFIER を使用してください。 |
UNSIGNED BIGINT |
DECIMAL(20) |
ダウンロードの場合、IBM DB2 LUW の値は負でない必要があります。 |
UNSIGNED INTEGER |
DECIMAL(11) |
ダウンロードの場合、IBM DB2 LUW の値は負でない必要があります。 |
UNSIGNED SMALLINT |
DECIMAL(5) |
ダウンロードの場合、IBM DB2 LUW の値は負でない必要があります。 |
UNSIGNED TINYINT |
SMALLINT |
ダウンロードの場合、IBM DB2 LUW の値は負でない必要があります。 |
VARBINARY(n<MRL) |
VARCHAR(n) FOR BIT DATA |
|
VARBINARY(n>=MRL) |
BLOB(n) |
|
VARBIT(n<MRL) |
VARCHAR(n) |
|
VARBIT(n>=MRL) |
CLOB(n) |
|
VARCHAR(n<MRL) |
VARCHAR(n) |
|
VARCHAR(n>=MRL) |
CLOB(n) |
IBM DB2 LUW の値が SQL Anywhere または Ultra Light の値より長い可能性があるので、ダウンロード時には値が大きすぎないことを確認してください。 |
XML |
CLOB(n) |
次の表は、IBM DB2 LUW の統合データ型がどのように SQL Anywhere および Ultra Light のリモートデータ型にマッピングされるのかを示します。たとえば、統合データベースの INT 型のカラムは、リモートデータベースでは INTEGER 型である必要があります。
IBM DB2 LUW テーブルを作成する場合は、ページサイズに注意する必要があります。IBM DB2 LUW には、ページサイズに基づく最大ロー長 (MRL) があります。ページサイズが 4K の場合の MRL は 4005 です。8K の場合は 8101、16K の場合は 16293、32K の場合は 32677 になります。テーブルに含まれる全カラムの長さがこの制限を超えることはできません。テーブルに BLOB または CLOB カラムがある場合は、BLOB または CLOB データを直接カウントするのではなく、LOB ロケータを使用してロー長をカウントできます。詳細については、IBM DB2 LUW のマニュアルを参照してください。
IBM DB2 LUW のデータ型 | SQL Anywhere または Ultra Light のデータ型 | 説明 |
---|---|---|
BLOB |
LONG BINARY |
|
BIGINT |
BIGINT |
|
CHAR(n) |
VARCHAR(n) |
SQL Anywhere には IBM DB2 LUW の CHAR に対応するデータ型がありません。同期される統合データベースのカラムでは、CHAR を使用しないでください。IBM DB2 LUW の CHAR カラムを同期させる必要がある場合は、-b オプションを指定して Mobile Link サーバーを実行してください。 |
CHAR(n) FOR BIT DATA |
BINARY(n) |
|
CLOB(n) |
LONG VARCHAR |
|
DATE |
DATE |
SQL Anywhere と Ultra Light では、時刻の値は 00:00:00 の形式である必要があります。 |
DB2GSE.ST_GEOMETRY |
ST_GEOMETRY |
|
DBCLOB(n) |
LONG VARCHAR |
DBCLOB(n) データ型は 2 バイト文字用にのみ使用します。SQL Anywhere には対応するデータ型がありません。IBM DB2 LUW の文字セットがユニコードの場合、DBCLOB(n) は CLOB と同じです。 |
DECIMAL(p,s) |
DECIMAL(p,s) |
|
DOUBLE |
DOUBLE |
DOUBLE は、丸め誤差が出る可能性がある概数値データ型です。種類の異なるコンピューターを使用すると、DOUBLE の基本となる記憶領域が異なることが多く、したがって、丸めの結果も異なります。プライマリキーは等しいかどうかの確認に使用されるので、プライマリキーで DOUBLE を使用することはおすすめできません。これは特に同期環境で言えます。特に、統合データベースはリモートデータベースとは異なるハードウェアで実行されることが多いからです。 |
FLOAT |
DOUBLE |
FLOAT はあいまいな値なので、統合データベースとリモートデータベースとで厳密に同じ値を使用できない場合、問題を引き起こすことがあります。取り得るすべての値がテスト済みであるわけではないので、注意が必要です。問題の発生を回避するため、このような型をプライマリキーの一部として使用しないでください。 |
GRAPHIC(n) |
VARCHAR(2n) |
IBM DB2 LUW の GRAPHIC にはブランクが埋め込まれますが、SQL Anywhere の CHAR には埋め込まれません。このデータ型は使用しないことをおすすめします。 GRAPHIC データ型は 2 バイト文字用にのみ使用します。SQL Anywhere には対応するデータ型がありません。IBM DB2 LUW の文字セットが Unicode の場合、GRAPHIC は CHAR と同じです。 |
INT |
INTEGER |
|
LONG VARCHAR |
VARCHAR(32700) |
|
LONG VARCHAR FOR BIT DATA |
VARBINARY(32700) |
|
LONG VARGRAPHIC(n) |
VARCHAR(32700) |
LONG VARGRAPHIC データ型は 2 バイト文字用にのみ使用します。SQL Anywhere には対応するデータ型がありません。IBM DB2 LUW の文字セットがユニコードの場合、LONG VARGRAPHIC は LONG VARCHAR と同じです。 |
NUMERIC(p,s) |
NUMERIC(p,s) |
|
REAL |
REAL |
REAL はあいまいな値なので、統合データベースとリモートデータベースとで厳密に同じ値を使用できない場合、問題を引き起こすことがあります。取り得るすべての値がテスト済みであるわけではないので、注意が必要です。問題の発生を回避するため、このような型をプライマリキーの一部として使用しないでください。 |
SMALLINT |
SMALLINT |
|
TIME |
TIME |
SQL Anywhere TIME 値の小数点以下の秒の値は、ダウンロード時にトランケートされます。問題を回避するには、小数点以下の秒を使用しないでください。TIME カラムの精度を保持するため、Mobile Link サーバーでは、TIME カラムが常に ODBC SQL_TYPE_TIMESTAMP データ型にバインドされます。統合データベースが DB2 9.7 サーバーで実行されているときは、カラムがプライマリキーの一部である場合、DB2 変換関数を使用してカラムを TIMESTAMP と TIME の間で明示的に変換する必要があります。 |
TIMESTAMP |
TIMESTAMP |
|
VARCHAR(n) |
VARCHAR(n) |
|
VARCHAR(n) FOR BIT DATA |
VARBINARY(n) |
|
VARGRAPHIC(n) |
VARCHAR(2n) |
VARGRAPHIC データ型は 2 バイト文字用にのみ使用します。SQL Anywhere には対応するデータ型がありません。IBM DB2 LUW の文字セットがユニコードの場合、VARGRAPHIC は VARCHAR と同じです。 |
![]() |
DocCommentXchange で意見交換できます
|
Copyright © 2012, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.1 |