DSQL - Corrected bad behavior when getting data with wrong datatype function
Functions for retrieving data from result set (such as ctsqlGetSmallInt and ctsqlGetDate) could give unexpected results if they were called on a column with a different data type. These two were very likely to crash the client if called on a column with a different data type:
ctsqlGetBytes
ctsqlGetBinary
The logic has been improved to correct this problem:
Logic has been added to the ctsqlGet<type> functions to perform type checking.
If the type is not correct and type checking is enabled (see below), CTSQLRET_INTYPES is returned.
If the type is not correct and type checking is NOT enabled (see below), the data is converted to the requested type. (ctsqlGetBytes and ctsqlGetBinary do not attempt conversion but simply return the binary content of the field.)
A new function, ctsqlSetTypeCheckOnGet(), has been added to turn on/off this type checking in case someone want to use the old behavior. The default is to have the checks on. The setting change applies immediately to the connection and all open cursors.
The following commands previously returned CTSQL_BADPARAM (-20127) when called with a wrong (typically NULL) argument. This error code was not correct, so these functions now return CTSQLRET_BADARG (-20068), which is the appropriate error. Note: This is a behavior change (it still fails, but with a different error).
ctsqlSetSSL
ctsqlSetPreserveCursor
ctsqlConnect
ctsqlDisconnect
ctsqlDetach
ctsqlBegin
ctsqlCommit
ctsqlAbort
ctsqlSetIsolationLevel
ctsqlSetAutoCommit
ctsqlSetParameter
ctsqlSetParameterScale
ctsqlSetParameterPrecision
ctsqlSetParameterPrecisionX (this function is not available in all DSQL versions)
