ODBCLink/SE Reference Manual |
| Application Development | ||
|
|
|
|
|
| DATE | SQL_DATE |
| |
|
|
| binary fields |
|
|
|
|
|
|
| TIME | SQL_TIME |
| |
|
|
| binary fields |
|
|
|
|
|
|
| DATETIME | SQL_TIMESTAMP |
| |
|
|
| (2), hour (2), minute (2), second (2), |
|
|
|
| fraction (4) |
|
|
|
|
|
|
| INTERVAL | SQL_CHAR | Format is “ddddddd hh:mm:ss.fff” |
|
|
|
|
|
|
Note: When creating a table using CHAR and BINARY data types that are greater than 255 characters the resulting data types used will be LONGVARCHAR and LONGVARBINARY, which may not be the data type expected by the the application.
Note on Using BLOBs
It is strongly recommended that when creating an ALLBASE table for storage of BLOBs that you use a LONG VARBINARY column. ALLBASE will allocate storage space according to the actual size of the BLOB. Eg. Creating a table with a column defined as LONG VARBINARY (200000000) and writing a 10K BLOB to it will result in only 10K of space being used (not the maximum of 2 GB as specified when the column was created).
Although you can store a BLOB using a LONG BINARY column, this is not recommended, because ALLBASE will allocate storage space according to the specified column size for each BLOB regardless of the size of the actual data. Eg. Creating a table with a column defined as LONG BINARY(1000000) and writing a 10K BLOB will result in 1000000 bytes of space being used for each BLOB. You would quickly run out of space in your database.
ODBCLink/SE |
|
©M.B. Foster Associates Limited | 35 |