V9 Update Guide

c-treeSQL and c-treeDB BINARY and VARBINARY Compatibility Issues

The V8 series of c-treeSQL Servers could conflict in the handling of CT_ARRAY field types when accessed by both c-tree ISAM and c-treeSQL. The following example illustrates the complexity of the issue.

Consider a simple c-tree Plus ISAM table with a CT_ARRAY field of 16 bytes imported into a c-treeSQL database. It was noted that the same table created with a simple c-tree Plus ISAM API created the CT_ARRAY field with 16 bytes (the DODA entry of the CT_ARRAY field had a length of 16) while an equivalent table created with c-treeSQL (using ISQL for example), created the table with a 20 byte CT_ARRAY field. Queries on this table can produce a c-treeSQL Server crash.

The c-treeSQL Server handled BINARY (mapped as CT_ARRAY) and VARBINARY (mapped as CT_2STRING) fields differently from c-treeDB. c-treeSQL maintains four bytes prepended to the data area to indicate the length of the field, however, c-treeDB did not require any length information about the data, and did not maintain this same four byte addition.

Furthermore, CT_2STRING field handling was even more complex as there already existed two bytes for the CT_2STRING field length, followed by the additional four bytes added by c-treeSQL.

For a customer, there are three potential situations that exist:

1. If a customer is using only c-treeSQL interfaces, ODBC, JDBC, ISQL, etc., the CT_ARRAY and CT_2STRING fields contain an extra four bytes at the beginning indicating how many bytes follow. As long as only c-treeSQL interfaces are used to create and maintain the tables, there are no issues.
2. If a customer is using only c-treeDB or c-tree Plus ISAM interfaces, the CT_ARRAY and CT_2STRING fields do not contain the extra four bytes at the beginning to indicate how many bytes follow. As long as c-treeSQL interfaces are NOT used to access these tables, there are no issues.
3. If a customer mixes c-treeSQL and c-treeDB operations in the same table, there exists a compatibility issue, possibly resulting in a c-treeSQL Server crash. Fields written by c-treeSQL and read by c-treeDB are safe: the data simply contains an extra four bytes at the start which must be accounted for at the application level. Fields written by c-treeDB and read by c-treeSQL are not safe: the first four bytes of the data are interpreted as a four byte integer by c-treeSQL indicating how many bytes will follow. This scenario will mostly likely result in a c-treeSQL Server crash with a memory violation exception.

Note: For V8 c-treeSQL installations, it is possible to design a c-treeDB or c-tree Plus application to properly account for this four byte discrepancy and still allow c-treeSQL to function properly over the tables.

This requires the tables to be created in one of two manners. The tables can be created with the extra four bytes of storage at the beginning of the CT_ARRAY or CT_2STRING fields with a non-c-treeSQL interface, and then import them into a c-treeSQL database. Alternatively, create the tables directly with a c-treeSQL interface.In either case, it is the application’s responsibility to determine and maintain the field length in the allotted space. However, this places a burden on the application developer with a dependency that is not generally expected.