When the Acu4GL for ODBC interface creates a table, it uses what it determines
to be the best match of a data type for any particular column.
This means that the database column will be able to hold any data that the
COBOL data type can hold, and is as close as possible to the type of data that the
COBOL program is using. This determination is based in part on what data
types the data source has available. Obviously, if a data source doesn't support
some data type, the Acu4GL for ODBC interface can't use it with that data
source. The actual algorithm used is rather complicated, but the general rules are
as follows:
1. User preferences take precedence. This means that the XFD directives specified are checked first. Therefore, when data should be of type DATE or BINARY, a DATE or BINARY type is located and used, if the data source supports it.
2. If the COBOL data type is usage float or usage double, a data source type of FLOAT, REAL, or DOUBLE is used, depending on what is available. If none of these is available, the interface abides by the next rule.
3. If the COBOL data type is numeric, a numeric type is used in the data source. The numeric type chosen depends on how large the COBOL data type is, and how many digits to the right of the decimal point (if any) there are.
For example, if the COBOL data type is PIC 99, the data source types checked for are TINYINT, SMALLINT, INTEGER, BIGINT, DECIMAL, NUMERIC, CHAR. The first of these that exists is the type that will be used for that column.
For another example, if the COBOL data type is PIC 9(6)v99, the data source types checked for are DECIMAL, NUMERIC, DOUBLE, FLOAT, REAL, CHAR. Again, the first of these types that exists is the type that will be used for that column.
4. Anything else will use CHAR.
Occasionally, you may encounter a data source type that only supports type CHAR (which is the only data type which is guaranteed to exist, according to the ODBC specification). Under these data sources, all the COBOL data types will be mapped to CHAR types.