The following table identifies how SQL Anywhere and UltraLite remote data types are mapped to IBM DB2 LUW consolidated data types. For example, a column of type BIT on the remote database should be type SMALLINT on the consolidated database.
When creating an IBM DB2 LUW table, you need to pay attention to the DB2 page size. IBM DB2 LUW has a maximum row length (MRL) based on the page size: the MRL is 4005 when the page size is 4K, 8101 when 8K, 16293 when 16K and 32677 when 32K. The length of all columns in a table cannot exceed the above limitation. If a table has a BLOB or CLOB column, you count row length using the LOB locator, not BLOB or CLOB data directly. For details, see the IBM DB2 LUW documentation.
SQL Anywhere or UltraLite data type | IBM DB2 LUW data type | Notes |
---|---|---|
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 values can be longer than SQL Anywhere or UltraLite values, so make sure values are not too big when downloading. |
DATE |
DATE |
For SQL Anywhere and UltraLite, the time value must in the format 00:00:00. |
DATETIME |
TIMESTAMP |
|
DECIMAL(p<32,s) |
DECIMAL(p,s) |
The precision of SQL Anywhere DECIMAL is between 1 and 127. The maximum precision of IBM DB2 LUW DECIMAL is 31. |
DECIMAL(p>=32,s) |
Any data of SQL Anywhere DECIMAL precision greater than 31 cannot be synchronized to IBM DB2 LUW. |
|
DOUBLE |
DOUBLE |
DOUBLE is an imprecise numeric data type that is subject to rounding. When working with different types of computers, the underlying storage of DOUBLE is often different, resulting in different rounding. DOUBLE is a bad choice to use in a primary key because primary keys are looking for equality. This is especially true in a synchronization environment because the consolidated database often runs on different hardware from the remote database. |
FLOAT(1-24) |
REAL |
FLOAT can cause problems if the consolidated and remote databases don't allow the exact same (imprecise) values. iAnywhere Solutions does not test all possible values, so care must be taken. To avoid problems, do not use these types as part of a primary key. |
FLOAT(25-53) |
DOUBLE |
FLOAT can cause problems if the consolidated and remote databases don't allow the exact same (imprecise) values. iAnywhere Solutions does not test all possible values, so care must be taken. To avoid problems, do not use these types as part of a primary key. |
IMAGE |
BLOB(n) |
|
INTEGER |
INTEGER |
|
LONG BINARY |
BLOB(n) |
|
LONG NVARCHAR |
CLOB(n) |
There is no corresponding data type in IBM DB2 LUW. If the IBM DB2 LUW character set is Unicode, SQL Anywhere LONG NVARCHAR can synchronize to IBM DB2 CLOB. UltraLite doesn't have LONG NVARCHAR. |
LONG VARBIT |
CLOB(n) |
|
LONG VARCHAR |
CLOB(n) |
|
MONEY |
DECIMAL(19,4) |
|
NCHAR(c) |
VARCHAR(n) or CLOB(n) |
There is no corresponding data type in IBM DB2 LUW. If the IBM DB2 LUW character set is Unicode, NCHAR can synchronize to IBM DB2 LUW VARCHAR or CLOB. The size of SQL Anywhere NCHAR is characters and the size of IBM DB2 LUW VARCHAR is bytes. If you map to VARCHAR, the total bytes of NCHAR can not be bigger than MRL. Otherwise, NCHAR should map to CLOB. It is difficult to calculate the number of bytes in NCHAR(c), but it is approximately c=n/4. In general, if c is less than MRL/4, map to VARCHAR(n), but if c is greater than or equal to MRL/4, map to CLOB(n). |
NUMERIC(p<32,s) |
NUMERIC(p,s) |
|
NUMERIC(p>=32,s) |
There is no corresponding data type in IBM DB2 LUW. |
|
NTEXT |
CLOB(n) |
There is no corresponding data type in IBM DB2 LUW. If the IBM DB2 LUW character set is Unicode, NTEXT can synchronize to IBM DB2 LUW CLOB. |
NVARCHAR(c) |
VARCHAR(n) or CLOB(n) |
There is no corresponding data type in IBM DB2 LUW. If the IBM DB2 LUW character set is Unicode, NVARCHAR can synchronize to IBM DB2 LUW VARCHAR or CLOB. The size of SQL Anywhere NVARCHAR is characters and the size of IBM DB2 LUW VARCHAR is bytes. If you map to VARCHAR, the total bytes of NVARCHAR can not be bigger than MRL. Otherwise, NVARCHAR should map to CLOB. It is difficult to calculate the number of bytes in NVARCHAR(c), but it is approximately c=n/4. In general, if c is less than MRL/4, map to VARCHAR(n), but if c is greater than or equal to MRL/4, map to CLOB(n). |
REAL |
REAL |
REAL can cause problems if the consolidated and remote databases don't allow the exact same (imprecise) values. iAnywhere Solutions does not test all possible values, so care must be taken. To avoid problems, do not use these types as part of a primary key. |
SMALLDATETIME |
TIMESTAMP |
|
SMALLINT |
SMALLINT |
|
SMALLMONEY |
DECIMAL(10,4) |
|
TEXT |
CLOB(n) |
|
TIME |
TIMESTAMP or TIME |
SQL Anywhere and UltraLite TIME values with fractional seconds require IBM DB2 LUW TIMESTAMP. SQL Anywhere and UltraLite time values with fractional seconds that are always zero can use IBM DB2 TIME. In order to preserve the precision of a time column, the MobiLink server always binds the TIME column with the ODBC SQL_TYPE_TIMESTAMP data type. When the consolidated database is running on a DB2 9.7 server, you may need to use DB2 conversion functions to explicitly convert the column between TIMESTAMP and TIME if the column is a part of a primary key. |
TIMESTAMP |
TIMESTAMP |
|
TIMESTAMP WITH TIME ZONE | VARCHAR(34) | There is no equivalent data type in IBM DB2 LUW. Therefore, a TIMESTAMP WITH TIME ZONE column should be mapped to a VARCHAR(34) column. In upload, the MobiLink server first converts the data to a string using the format YYYY-MM-DD HH:NN:SS.SSSSSS [+|-]HH:NN and then applies it to the consolidated database. In download, it converts the data from string to TIMESTAMP WITH TIME ZONE. Ensure the data in the consolidated database follows this format or the download will fail. |
TINYINT |
SMALLINT |
For download, IBM DB2 LUW values must be non-negative. |
UNIQUEIDENTIFIER |
CHAR(36) |
|
UNIQUEIDENTIFIERSTR |
CHAR(36) |
UNIQUEIDENTIFIERSTR is not recommended for IBM DB2 LUW. Use UNIQUEIDENTIFIER instead. |
UNSIGNED BIGINT |
DECIMAL(20) |
For download, IBM DB2 LUW values must be non-negative. |
UNSIGNED INTEGER |
DECIMAL(11) |
For download, IBM DB2 LUW values must be non-negative. |
UNSIGNED SMALLINT |
DECIMAL(5) |
For download, IBM DB2 LUW values must be non-negative. |
UNSIGNED TINYINT |
SMALLINT |
For download, IBM DB2 LUW values must be non-negative. |
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 values can be longer than SQL Anywhere or UltraLite values, so make sure values are not too big when downloading. |
XML |
CLOB(n) |
The following table identifies how IBM DB2 LUW consolidated data types are mapped to SQL Anywhere and UltraLite remote data types. For example, a column of type INT on the consolidated database should be type INTEGER on the remote database.
When creating an IBM DB2 table, you need to pay attention to the page size. IBM DB2 has a maximum row length based on the page size: the MRL is 4005 when the page size is 4K, 8101 when 8K, 16293 when 16K and 32677 when 32K. The length of all columns in a table cannot exceed the above limitation. If a table has a BLOB or CLOB column, you count row length using the LOB locator, not BLOB or CLOB data directly. For details, see the IBM DB2 documentation.
IBM DB2 LUW data type | SQL Anywhere or UltraLite data type | Notes |
---|---|---|
BLOB |
LONG BINARY |
|
BIGINT |
BIGINT |
|
CHAR(n) |
VARCHAR(n) |
There is no equivalent to IBM DB2 LUW CHAR in SQL Anywhere. You should not use CHAR in a consolidated database column that is synchronized. If you must synchronize IBM DB2 LUW CHAR columns, run MobiLink server with the -b option. |
CHAR(n) FOR BIT DATA |
BINARY(n) |
|
CLOB(n) |
LONG VARCHAR |
|
DATE |
DATE |
For SQL Anywhere and UltraLite, the time value must in the format 00:00:00. |
DBCLOB(n) |
LONG VARCHAR |
The data type DBCLOB(n) is only used for double-byte characters. SQL Anywhere does not have a corresponding data type. When the IBM DB2 LUW character set is Unicode, DBCLOB(n) is equivalent to CLOB. |
DECIMAL(p,s) |
DECIMAL(p,s) |
|
DOUBLE |
DOUBLE |
DOUBLE is an imprecise numeric data type that is subject to rounding. When working with different types of computers, the underlying storage of DOUBLE is often different, resulting in different rounding. DOUBLE is a bad choice to use in a primary key because primary keys are looking for equality. This is especially true in a synchronization environment because the consolidated database often runs on different hardware from the remote database. |
FLOAT |
DOUBLE |
FLOAT can cause problems if the consolidated and remote databases don't allow the exact same (imprecise) values. iAnywhere Solutions does not test all possible values, so care must be taken. To avoid problems, do not use these types as part of a primary key. |
GRAPHIC(n) |
VARCHAR(2n) |
IBM DB2 LUW GRAPHIC does blank-padding, but SQL Anywhere CHAR does not. It is recommended that you do not use this data type. The data type GRAPHIC is only used for double-byte characters. SQL Anywhere does not have a corresponding data type. When the IBM DB2 LUW character set is Unicode, GRAPHIC is equivalent to CHAR. |
INT |
INTEGER |
|
LONG VARCHAR |
VARCHAR(32700) |
|
LONG VARCHAR FOR BIT DATA |
VARBINARY(32700) |
|
LONG VARGRAPHIC(n) |
VARCHAR(32700) |
The data type LONG VARGRAPHIC is only used for double-byte characters. SQL Anywhere does not have a corresponding data type. When the IBM DB2 LUW character set is Unicode, LONG VARGRAPHIC is equivalent LONG VARCHAR. |
NUMERIC(p,s) |
NUMERIC(p,s) |
|
REAL |
REAL |
REAL can cause problems if the consolidated and remote databases don't allow the exact same (imprecise) values. iAnywhere Solutions does not test all possible values, so care must be taken. To avoid problems, do not use these types as part of a primary key. |
SMALLINT |
SMALLINT |
|
TIME |
TIME |
The fractional seconds values from SQL Anywhere TIME values are truncated on download. To avoid problems, do not use fractional seconds. In order to preserve the precision of a TIME column, the MobiLink server always binds the time column with the ODBC SQL_TYPE_TIMESTAMP data type. When the consolidated database is running on a DB2 9.7 server, you may need to use DB2 conversion functions to explicitly convert the column between TIMESTAMP and TIME if the column is a part of a primary key. |
TIMESTAMP |
TIMESTAMP |
|
VARCHAR(n) |
VARCHAR(n) |
|
VARCHAR(n) FOR BIT DATA |
VARBINARY(n) |
|
VARGRAPHIC(n) |
VARCHAR(2n) |
The data type VARGRAPHIC is only used for double-byte characters. SQL Anywhere does not have a corresponding data type. When the IBM DB2 LUW character set is Unicode, VARGRAPHIC is equivalent to VARCHAR. |
Discuss this page in DocCommentXchange.
|
Copyright © 2010, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.0 |