Informix Online Documentation |
Date: 10/15/99
Version: 3.31
The purpose of these release notes is to make you aware of any special actions required to configure and use the Informix ODBC Driver on your computer. This file also contains information about known bugs and their workarounds.
This release notes document is not intended to be all-inclusive; it should be used as an addendum to the Informix ODBC Driver, which provides thorough information about product features and behavior.
These release notes are written for the following audience:
Version 3.31of Informix ODBC Driver has been tested with the following database server configurations:
This manual might not reflect the latest names of Informix database servers. The following table lists the database server versions and their corresponding names.
Informix ODBC3.31 driver shows the following utilization and optimization improvements:
ODBC 3.31 driver supports existing applications, which support standard ODBC Data types only. A new DSN option "Report Standard ODBC Types" should be checked ON to expect this behavior. Example applications: Powerbuilder, MS-Access, VisualBasic etc.
When an application sets this option, the driver sets the following behavior:
However, each of the above behavior can be controlled alone as a connection or a statement level options. Informix ODBC 3.31 driver supports three new connection and statement level attributes:
Applications can use SQLSetConnectAttr, SQLSetStmtAttr to set/unset these values. (ODBC 2.x applications can use SQLSetConnectOptions, SQLSetStmtOptions equivalently).
Check this options under the advanced tab of the ODBC Administration for Informix Driver DSN. [default is 0]
Add a new DSN option "NeedODBCTypesOnly" under your DSN setting in your .odbc.ini file. [default is 0]. For example:
[Informix9]
Driver=/informix/lib/cli/libthcli.so
Description=Informix ODBC 3.31 Driver
.
NeedODBCTypesOnly=1
The following table shows how the INFORMIX 9 data types map to the standard ODBC data types. These types are in addition to the INFORMIX data types.
Note: for Multiset, Set, Row and List data types, the data type is mapped to the defaultUDTFetchType attribute set i.e. SQL_C_CHAR or SQL_C_BINARY.
Applications can set this attribute to value SQL_TRUE or SQL_FALSE. This attribute can be set/unset at connection and statement level. All the statements allocated under same connection will inherit this value. Alternatively each statement can change this attribute also. By default this attribute is set to SQL_FALSE.
An application can change the value of this attribute using the SQLSetConnectAttr and SQLSetStmtAttr (SQLSetConnectOption and SQLSetStmtOption in ODBC 2.x). Applications can retrieve the values set using SQLGetConnectAttr and SQLGetStmtAttr (SQLGetConnectOption and SQLGetStmtOption in ODBC 2.x)
NOTE: The connection/statement attribute SQL_INFX_ATTR_ODBC_TYPES_ONLY cannot be set to SQL_TRUE when SQL_INFX_ATTR_LO_AUTOMATIC is set SQL_FALSE.
Error reported: Attribute Cannot be set. LoAutomatic should be ON to set this value
Application should first set the SQL_INFX_ATTR_LO_AUTOMATIC attribute to SQL_TRUE and then set the attribute SQL_INFX_ATTR_ODBC_TYPES_ONLY to SQL_TRUE.
Applications can set this attribute to value SQL_TRUE or SQL_FALSE. This attribute can be set/unset at connection and statement level. All the statements allocated under same connection will inherit this value. Alternatively each statement can change this attribute also. By default this attribute is set to SQL_FALSE.
An application can change the value of this attribute using the SQLSetConnectAttr and SQLSetStmtAttr (SQLSetConnectOption and SQLSetStmtOption in ODBC 2.x). Applications can retrieve the values set using SQLGetConnectAttr and SQLGetStmtAttr (SQLGetConnectOption and SQLGetStmtOption in ODBC 2.x)
NOTE: The connection/statement attribute SQL_INFX_ATTR_LO_AUTOMATIC cannot be set to SQL_FALSE when SQL_INFX_ATTR_ODBC_TYPES_ONLY is set SQL_TRUE.
Error reported: Attribute Cannot be set. ODBC types only should be OFF to set this value
Application should first set the attribute SQL_INFX_ODBC_TYPES_ONLY to SQL_FALSE and then set the attribute SQL_INFX_ATTR_LO_AUTOMATIC to SQL_FALSE.
Application can set this attribute to SQL_C_CHAR or SQL_C_BINARY to set the default fetch type for UDTs. The default value of this attribute is set depending on following conditions.
If the DSN setting for "Report ODBC Types only" is ON, the value of DefaultUDTFetchType is set to SQL_C_CHAR.
If the DSN setting for "Report ODBC Types only" is OFF, the value of DefaultUDTFetch is set to SQL_C_BINARY.
If a user has set a registry key (feature added in ODBC 3.30), the value of DefaultUDTFetchType is set to the value in registry provided "Report ODBC Types Only" is not set.
An application can change the value of this attribute using the SQLSetConnectAttr and SQLSetStmtAttr (SQLSetConnectOption and SQLSetStmtOption in ODBC 2.x). Applications can retrieve the values set using SQLGetConnectAttr and SQLGetStmtAttr (SQLGetConnectOption and SQLGetStmtOption in ODBC 2.x)
NOTE: Setting the "Report ODBC Types only" to ON, will always override the DefaultUDTFetchType to SQL_C_CHAR.
This section describes the known problems with this release of the Informix ODBC Driver and, if possible, shows how to work around these problems.
SQLGetData puts the wrong value in the length or indicator pointer when selecting an interval day to hour into an SQL_C_CHAR.
Actually the described problem is fixed, however, the application (MS ACCESS) still fails, the Interval day to hour data displays as #DELETED. We believe it to be a problem with the way that MS Access handles Intervals. We are working with Microsoft on this.
XA close connection should check for return state while closing any active statements - some statements might still be executing (_odbc_s8).
This will happen only when the application is not using a Driver manager. The workaround is to be sure that all statements are closed before calling SQLDisconnect on XA connections.
If the procedure name has an '_' then the ODBC driver will send the wrong procedure name to the data source. For example: when doing following statement through dbaccess: execute procedure info8@ergms 1:"sdu".rp 1(1);
The ODBC driver will send the following SQL statement to server:
"execute procedure "sdu".rp _1(1)"
The procedure name has an added space between rp and _1. No workaround.
Use the decode function on a UNIX server through odbc connection and you get error 800. The decode function is as simple as:
select decode(count(*),0,1,count(*)) from state;
The same works fine if the engine is on NT.
When executing a stored procedure with a return value through ADO 2.0/2.1 via the recordset.open() method, the ODBC driver treats the call as a cursor, performing an SQLExecDirect followed later by an SQLExtendedFetch. If an error occurs inside the stored procedure, per the fix to bug 109768 and its duplicate 111703, the error is now returned successfully to the ODBC driver against the SQLExtendedFetch. The problem with this is that when ADO executes a statement via the recordset.open() method, ADO ONLY looks to SQLExecDirect for a return code. Therefore, using a Visual Basic front-end application, the error is never reported to the application, and therefore the operation appears to complete successfully.
Some stored procedure errors can not be returned until the stored procedure is executed and the data is fetched. ADO is ignoring any error returned by SQLExtendedFetch. We are working with Microsoft on this problem.
No rows will be returned on Visual Basic, if the query is an outer join and one of the columns contains null values
When using MSAccess97 or MSquery to link to a table through the Informix 3.30 ODBC drivers on NT4.0, certain table names such as those containing 18 characters which are made up of two or more underscores cause:
Invalid string of buffer length.
(#-11071) error to occur, and the table can not be accessed.
Incorrect information reported from SQLColumns on a DATETIME year to second.
Select of a interval column returns error - 2147217887 (80040e21) from a Visual Basic application that uses ODBC 3.30 to do the connection.
When executing a query (create view) through DAO (database.execute), it sometimes comes back with a "can not reference memory" error.
On Solaris platforms, the ODBC Driver Manager is not linked to the libnsl.so network service library. You must initialize this library before you invoke the ODBC driver.
To ensure maximum ODBC compatibility, link the libnsl.so library to your application.
The following problems have been fixed since the 3.30.TC1 release of Informix ODBC Driver in ClientSDK 2.30:
Informix ODBC Driver fails to populate ROWCOUNT property of RDORESULTSET object in a Visual Basic program unless a MOVELAST method is explicitly executed.
This bug causes ODBC Error S1000: [Informix][Informix ODBC Driver] An illegal character has been found in the statement.
Informix Servers can not accept literal strings that contain the newline (NL) character.
Informix Servers can not insert a literal string into TEXT simple BLOBs.
UNIX, linking with both the DMR (Informix Driver manager replacement) and the threading library statically is not threadsafe with trace on.
Insert Cursor support does not work with 9.x servers.
Using connectdatabase=no and creating a new database will fail to get database information, which will cause problems with setting options.
Insert cursors don't work in non-ansi logging database with auto-commit.
On Windows NT platforms, when using the DSN setup utility, the test connection button does not take the latest modified value that you enter for 'SERVICE'. For example, if you create a new data source name using a valid server name, host name, service, etc., and then click the 'Test Connection' button, the message 'Test Connection was successful' appears. However, if you subsequently edit the data source name by clicking the 'Configure' button, select the Connection tab and modify the value of 'SERVICE' to one that does not exist for the server name, then click 'Test Connection', you will still receive the 'Test Connection was successful' message.
When autocommit mode is turned on, the driver should not issue commit messages when trying to do an explicit BEGIN WORK.
When using a non-ANSI, logging database with autocommit mode, the driver gives the following error when the BEGIN WORK command is commented out:
-524: Lock table can only be used within a transaction.
The ifx_rc_count function, which is supposed to the return either the number of fields for a row type, or the cardinality of a collection, currently returns the correct value multiplied by 256.
In the ODBC data source setup, the OptimizeAutocommit check box should be set ON (checked) by default. This is a Windows only problem, as for UNIX, this value is set on by default.
In homogeneous environments, where the server and the client both have the same floating point format, the conversion from float to SQL_NUMERIC will fail when fetching floats from the server. On heterogeneous environments (such as between an Intel and a Sparc,) the conversion works, as data is converted by the server to a normalized decimal before being sent across the network.
When using batched insert cursors, having some rows marked as SQL_DATA_AT_EXEC and some not will cause the application to hang, waiting on the pipe for the server. This happens on UNIX & Windows.
In SQLBrowseConnect if user give an incomplete string like "DRIVER=Informix 3.30 32 BIT" and "DSN=infd33nt73nt". The response in OutConnect string is also the same what user has sent in InConnString.
SQLDescribeCol for byte column returns column size of 0.
I f you use Informix ODBC Driver against a Metacube decision support system that contains synonyms, columns from synonym tables are not visible from within the Data Warehouse Manager. Specifically, if you upgrade to tables in another database from a Metacube 4.0 DSS system that contains synonyms, Informix ODBC Driver cannot see the columns in those synonym tables from within the Data Warehouse Manager.
This problem existed on all Informix servers. Informix ODBC 3.30 could only process synonyms that were within the same database. Informix ODBC 3.31 now processes synonyms that are within different databases on the same or different server.
On Windows platforms, an insert or an update of a row or collection element that is a VARCHAR type results in a crash. Inserting into or updating a varchar field within a row or a collection will overwrite one byte before the start of an internally allocated buffer, resulting in an inconsistent memory buffer header. This eventually results in a crash, at a later point in the free() C library function.
Querying dates from a table with a column defined as datetime year to month. A date entered as 1998-11 through dbaccess is translated to 10/31/98 in Microsoft Access or Microstrategy.
ODBC Driver gives error on disconnect when:
1) OptimizeAutoCommit option in the DSN is not checked and
2) The application has set the SQL_ATTR_AUTOCOMMIT connection flag to OFF and
3) Last call to SQLExecDirect for a non result generating SQL statement fails
Catalog functions crash, they try to modify string constants passed as arguments. String constants can be read only as passed by the application (found with applications compiled with /ZF option on NT, or using Solaris SC5.0 compiler). Driver should make copies of strings passed before modifying them.
Linking an Informix table with UDT column via ODBC to MSAccess or querying on a UDT column in VB raises error -11013.(Errorcode "-11013 Restricted data type attribute violation")A similar query executed via an ASP page (also using the 3.3 driver) executes correctly.
A new DSN option on the "Advanced" tab, "Report Standard ODBC Types Only" enables emulation of all extended types as ODBC standard types. This may also be set as Connection and Statement attributes (See New Features section).
Synonyms within the database do not work correctly.
SQLColAttributes (SQL_COLUMN_TYPE) returns incorrect type for columns of type DATE, TIME, and TIMESTAMP. Correct values returned by CLI 2.8 and Intersolv 3.x drivers.
When doing a SELECT SQL on a table which contains Informix UDT rowtype, from dbaccess and sqleditor is fine but using Informix ODBC 3.30 fails with "out of range" error -11064. It looks like our odbc driver can't map/bind UDO types to be displayed in a application such as MS Access and Msquery.
ADO returns an Error when retrieving a Datetime Hour to Minute through Informix ODBC driver. ADO returns 11/11/1200 with proper Hour to Minute values when using the Intersolv driver.
ODBC does not detect DELIMIDENT in order to determine whether to search for the exact upper and lowercase characters in a table/column name etc. It simply ignores DELIMIDENT and searches for the table/column in lowercase. (see New Features section above).
MS-ACCESS can not link to an IUS table which has clob or blob column, an ODBC error (S1C00 Driver not capable) is returned.
Fetching an opaque type, which has an implicit cast to integer, into abound integer host variable will fail with state HY004: SQL data type out of range. Instead, the fetch should work if a cast is allowed between the types. This problem exists for all opaque types which are to be fetched into types other than SQL_C_BINARY or SQL_C_CHAR. The output buffers must be bound using SQLBindCol, before the fetch, and not using SQLGetData, after the fetch, or else the server side cast functions can not be employed. A related problem occurs when fetching complex types, such as collections, into char buffers. (See bug # 114736.)
The driver does not generate cursor names according to the ODBC standard. This results in sometimes getting the error 'invalid cursor name'
Setting the "ODBC Cursor Behavior=preserve" using the ODBC Administrator doesn't set the behavior to "preserve" it is still set to "close"
Fetching distinct columns without binding columns return incorrect results. Send RET_TYPE to server for distinct types. Otherwise the server sends the data in ASCII format with UDT headers.
With preserve/hold cursors enabled (cursorbehavior=1) commit work now incorrectly closes cursor
Selecting any data from a new Informix server will always hang the client. This will happen with ODBC 3.30 against a version 9.3 server (aka "Informix Dynamic Server 2000") or later version.
SQLColumns does not return the default values and NOT NULL properties of columns.
NEEDODBCTYPESONLY has replaced DefaultUDTFetchType, however, for 3.30 applications DSNs we still need to process it correctly. 3.30 customers had to insert it via regedit.exe. If present in the registry or the connection string it should be handled correctly by setting the correct flag in the connection structure.
Informix ODBC Driver has the following new Finder messages. The error-message number appears above the error-message text.
Attempt to fetch before the result returned the first rowset.
This Informix ODBC error code is the same as SQLSTATE value 01S06. The following functions can return this error code: SQLExtendedFetch and SQLFetchScroll
For SQLExtendedFetch(), the requested rowset overlapped the start of the result set when the current position was beyond the first row, and either FetchOrientation was SQL_PRIOR, or FetchOrientation was SQL_RELATIVE with a negative FetchOffset whose absolute value was less than or equal to the current SQL_ROWSET_SIZE. (Function returns SQL_SUCCESS_WITH_INFO.)
For SQLFetchScroll, the requested rowset overlapped the start of the result set when FetchOrientation was SQL_FETCH_PRIOR, the current position was beyond the first row, and the number of the current row is less than or equal to the rowset size.
The requested rowset overlapped the start of the result set when FetchOrientation was SQL_FETCH_PRIOR, the current position was beyond the end of the result set, and the rowset size was greater than the result set size.
The requested rowset overlapped the start of the result set when FetchOrientation was SQL_FETCH_RELATIVE, FetchOffset was negative, and the absolute value of FetchOffset was less than or equal to the rowset size.
The requested rowset overlapped the start of the result set when FetchOrientation was SQL_FETCH_ABSOLUTE, FetchOffset was negative, and the absolute value of FetchOffset was greater than the result set size but less than or equal to the rowset size.(Function returns SQL_SUCCESS_WITH_INFO.)
Invalid bookmark value.
This Informix ODBC error code is the same as SQLSTATE value HY111 (ODBC2.x state is S1111). The following functions can return this error code: SQLExtendedFetch and SQLFetchScroll
For SQLExtendedFetch, the argument FetchOrientation was SQL_FETCH_BOOKMARK and the bookmark specified in the FetchOffset argument was not valid.
For SQLFetchScroll, the argument FetchOrientation was SQL_FETCH_BOOKMARK and the bookmark pointed to by the value in the SQL_ATTR_FETCH_BOOKMARK_PTR statement attribute was not valid or was a null pointer.
Invalid attribute value
This Informix ODBC error code is the same as SQLSTATE value. The following functions can return this error code: SQLSetConnectAttr, SQLSetEnvAttr and SQLSetStmtAttr
For SQLSetConnectAttr, given the specified Attribute value, an invalid value was specified in ValuePtr. (The Driver Manager returns this SQLSTATE only for connection and statement attributes that accept a discrete set of values, such as SQL_ATTR_ACCESS_MODE or SQL_ATTR_ASYNC_ENABLE. For all other connection and statement attributes, the driver must verify the value specified in ValuePtr.)
The Attribute argument was SQL_ATTR_TRACEFILE or SQL_ATTR_TRANSLATE_LIB, and ValuePtr was an empty string.
For SQLSetEnvAttr, given the specified Attribute value, an invalid value was specified in ValuePtr.
For SQLSetStmtAttr, given the specified Attribute value, an invalid value was specified in ValuePtr. (The Driver Manager returns this SQLSTATE only for connection and statement attributes that accept a discrete set of values, such as SQL_ATTR_ACCESS_MODE or SQL_ ATTR_ASYNC_ENABLE. For all other connection and statement attributes, the driver must verify the value specified in ValuePtr.)
The Attribute argument was SQL_ATTR_APP_ROW_DESC or SQL_ATTR_APP_PARAM_DESC, and ValuePtr was an explicitly allocated descriptor handle that is not on the same connection as the StatementHandle argument.
Optional feature not implemented
This Informix ODBC error code is the same as SQLSTATE value HYC00. The following functions can return this error code: SQLBindCol, SQLBindParameter, SQLBulkOperations, SQLColAttribute, SQLColumnPrivileges, SQLColumns, SQLDriverConnect, SQLEndTran, SQLExecDirect, SQLExecute, SQLExtendedFetch, SQLFetch, SQLFetchScroll, SQLForeignKeys, SQLGetConnectAttr, SQLGetData,
SQLGetEnvAttr, SQLGetInfo, SQLGetStmtAttr, SQLGetTypeInfo, SQLParamData, SQLPrepare, SQLPrimaryKeys, SQLProcedureColumns, SQLProcedures, SQLSetConnectAttr, SQLSetEnvAttr, SQLSetPos, SQLSetStmtAttr, SQLSpecialColumns, SQLStatistics, SQLTablePrivileges and SQLTables
The value specified for the argument Attribute was a valid ODBC environment attribute for the version of ODBC supported by the driver, but was not supported by the driver. For more detailed information see the ODBC Reference Manual.
Invalid name of File DSN.
This Informix ODBC error code is the same as SQLSTATE value IM014. The following function can return this error code: SQLDriverConnect.
For SQLDriverConnect, the string in InConnectionString contained a FILEDSN keyword, but the name of the .DSN file was invalid.
Invalid descriptor index
This Informix ODBC error code is the same as SQLSTATE value 07009. The following functions can return this error code: SQLBindCol, SQLBindParameter, SQLBulkOperations, SQLColAttribute, SQLDescribeCol, SQLFetch SQLFetchScroll, SQLGetData, SQLGetDescField, SQLGetDescRec, SQLSetDescField, SQLSetDescRec and SQLSetPos.
For SQLBindCol, SQLBindParameter, SQLColAttribute, SQLGetData and SQLDescribeCol the value specified for column exceeded the maximum number of columns in the result set.
For SQLBulkOperations, the argument Operation was SQL_ADD and a column was bound with a column number greater than the number of columns in the result set.
For SQLFetch, the driver was an ODBC 2.x driver that does not support SQLExtendedFetch, and a column number specified in the binding for a column was 0.
For SQLFetchScroll, Column 0 was bound and the SQL_ATTR_USE_BOOKMARKS statement attribute was set to SQL_UB_OFF.
For SQLSetDescField and SQLGetDescField, The RecNumber argument was equal to 0, the SQL_ATTR_USE_BOOKMARK statement attribute was SQL_UB_OFF, and the DescriptorHandle argument was an IRD handle. (This error can be returned for an explicitly allocated descriptor only if the descriptor is associated with a statement handle.)The FieldIdentifier argument was a record field, the RecNumber argument was 0, and the DescriptorHandle argument was an IPD handle.The RecNumber argument was less than 0.
For SQLSetDescRec and SQLGetDescRec, the FieldIdentifier argument was a record field, the RecNumber argument was set to 0, and the DescriptorHandle argument was an IPD handle.(DM) The RecNumber argument was set to 0, and the SQL_ATTR_USE_BOOKMARKS statement attribute was set to SQL_UB_OFF, and the DescriptorHandle argument was an IRD handle.The RecNumber argument was less than 0.
For SQLSetPos, the argument Operation was SQL_REFRESH or SQL_UPDATE, and a column was bound with a column number greater than the number of columns in the result set.
Invalid datetime format.
This Informix ODBC error code is the same as SQLSTATE value 22007. The following functions can return this error code: SQLBulkOperations, SQLExecDirect,
SQLExecute, SQLExtendedFetch, SQLFetch, SQLFetchScroll, SQLGetData, SQLPutData and SQLSetPos
For SQLBulkOperations, the Operation argument was SQL_ADD, and the assignment of a date or timestamp value to a column in the result set caused the year, month, or day field to be out of range.
For SQLExecDirect and SQLExecute, StatementText contained an SQL statement that contained a date, time, or timestamp structure as a bound parameter and the parameter was, respectively, an invalid date, time, or timestamp.
For SQLFetch, SQLExtendedFetch, SQLGetData and SQLFetchScroll, a character column in the result set was bound to a date, time, or timestamp C structure, and a value in the column was, respectively, an invalid date, time, or timestamp.
For SQLPutData, an input/output or output parameter was bound to a date, time, or timestamp C structure, and a value in the returned parameter was, respectively, an invalid date, time, or timestamp. (Function returns SQL_SUCCESS_WITH_INFO.)
For SQLSetPos, the argument Operation was SQL_UPDATE, and the assignment of a date or timestamp value to a column in the result set caused the year, month, or day field to be out of range. The argument Operation was SQL_REFRESH, and returning the date or timestamp value for one or more bound columns would have caused the year, month, or day field to be out of range.
Interval field overflow.
This Informix ODBC error code is the same as SQLSTATE value 22015. The following functions can return this error code: SQLBulkOperations, SQLExecDirect,
SQLExecute, SQLExtendedFetch, SQLFetch, SQLFetchScroll, SQLGetData, SQLPutData and SQLSetPos
For SQLBulkOperations, the Operation argument was SQL_ADD or SQL_UPDATE_BY_BOOKMARK, and the assignment of a date or timestamp value to a column in the result set caused the year, month, or day field to be out of range.
For SQLExecute and SQLExecDirect, StatementText contained an exact numeric or interval parameter that when converted to an interval SQL data type caused a loss of significant digits.*StatementText contained an interval parameter with more than one field that when converted to a numeric data type in a column had no representation in the numeric data type.*StatementText contained parameter data that was assigned to an interval SQL type, and there was no representation of the value of the C type in the interval SQL type.Assigning an input/output or output parameter that was an exact numeric or interval SQL type to an interval C type caused a loss of significant digits.When an input/output or output parameter was assigned to an interval C structure, there was no representation of the data in the interval data structure.
SQLExtendedFetch, SQLFetch, SQLGetData and SQLFetchScroll, assigning from an exact numeric or interval SQL type to an interval C type caused a loss of significant digits in the leading field.When fetching data to an interval C type, there was no representation of the value of the SQL type in the interval C type.
For SQLPutData, the data sent for an exact numeric or interval column or parameter to an interval SQL data type caused a loss of significant digits. Data was sent for an interval column or parameter with more than one field, and was converted to a numeric data type, and had no representation in the numeric data type. The data sent for column or parameter data was assigned to an interval SQL type, and there was no representation of the value of the C type in the interval SQL type. The data sent for an exact numeric or interval C column or parameter to an interval C type caused a loss of significant digits. The data sent for column or parameter data was assigned to an interval C structure, and there was no representation of the data in the interval data structure.
For SQLSetPos, the Operation argument was SQL_UPDATE, and the assignment of an exact numeric or interval C type to an interval SQL data type caused a loss of significant digits.The Operation argument was SQL_UPDATE; when assigning to an interval SQL type, there was no representation of the value of the C type in the interval SQL type.The Operation argument was SQL_REFRESH, and assigning from an exact numeric or interval SQL type to an interval C type caused a loss of significant digits in the leading field.The Operation argument was SQL_ REFRESH; when assigning to an interval C type, there was no representation of the value of the SQL type in the interval C type.
Invalid character value for cast specification.
This Informix ODBC error code is the same as SQLSTATE value 22018. The following functions can return this error code: SQLBulkOperations, SQLExecDirect,
SQLExecute, SQLExtendedFetch, SQLFetch, SQLFetchScroll, SQLGetData, SQLPutData and SQLSetPos
For SQLBulkOperations, the argument Operation was SQL_ADD; the SQL type was an exact or approximate numeric, a datetime, or an interval data type; the C type was SQL_C_CHAR; and the value in the column was not a valid literal of the bound SQL type.
For SQLExecute and SQLExecDirect, StatementText contained a C type was an exact or approximate numeric, a datetime, or an interval data type; the SQL type of the column was a character data type; and the value in the column was not a valid literal of the bound C type.When an input/output or output parameter was returned, the SQL type was an exact or approximate numeric, a datetime, or an interval data type; the C type was SQL_C_CHAR; and the value in the column was not a valid literal of the bound SQL type.
For SQLExtendedFetch, SQLFetch, SQLFetchScroll and SQLGetData, a character column in the result set was returned to a character C buffer and the column contained a character for which there was no representation in the character set of the buffer.The C type was an exact or approximate numeric, a datetime, or an interval data type; the SQL type of the column was a character data type; and the value in the column was not a valid literal of the bound C type.
For SQLPutData, the C type was an exact or approximate numeric, a datetime, or an interval data type; the SQL type of the column was a character data type; and the value in the column or parameter was not a valid literal of the bound C type. The SQL type was an exact or approximate numeric, a datetime, or an interval data type; the C type was SQL_C_CHAR; and the value in the column or parameter was not a valid literal of the bound SQL type.
For SQLSetPos, the Operation argument was SQL_REFRESH; the C type was an exact or approximate numeric, a datetime, or an interval data type; the SQL type of the column was a character data type; and the value in the column was not a valid literal of the bound C type.The argument Operation was SQL_UPDATE; the SQL type was an exact or approximate numeric, a datetime, or an interval data type; the C type was SQL_C_CHAR; and the value in the column was not a valid literal of the bound SQL type.
Invalid application buffer type.
This Informix ODBC error code is the same as SQLSTATE value HY003. The following functions can return this error code: SQLBindCol, SQLBindParameter and SQLGetData.
For SQLBindCol and SQLGetData, the argument TargetType was neither a valid data type nor SQL_C_DEFAULT.
For SQLBindParameter, the value specified by the argument ValueType was not a valid C data type or SQL_C_DEFAULT.
Associated statement is not prepared
This Informix ODBC error code is the same as SQLSTATE value HY007. The following functions can return this error code: SQLCopyDesc, SQLGetDescField and SQLGetDescRec
For SQLCopyDesc, SQLGetDescField and SQLGetDescRec, DescriptorHandle was associated with a StatementHandle as an IRD, and the associated statement handle had not been prepared or executed.
Invalid use of null pointer.
This Informix ODBC error code is the same as SQLSTATE value HY009. The following functions can return this error code: SQLAllocHandle, SQLBindParameter,
SQLColumnPrivileges, SQLColumns, SQLExecDirect, SQLForeignKeys,
SQLNativeSql, SQLPrepare, SQLPrimaryKeys, SQLProcedureColumns, SQLProcedures, SQLPutData, SQLSetConnectAttr, SQLSetCursorName, SQLSetEnvAttr, SQLSetStmtAttr, SQLSpecialColumns, SQLStatistics, SQLTablePrivileges and SQLTables
For SQLAllocHandle, SQLExecDirect, SQLNativeSql, SQLPrepare, SQLPutData, SQLSetConnectAttr, SQLSetCursorName, SQLSetEnvAttr and SQLSetStmtAttr, the argument was a null pointer.
For SQLForeignKeys, SQLPrimaryKeys, SQLStatistics, SQLTablePrivileges and SQLTables, the TableName argument was a null pointer. The SQL_ATTR_METADATA_ID statement attribute was set to SQL_TRUE, the CatalogName argument was a null pointer, and the SQL_CATALOG_NAME InfoType returns that catalog names are supported. The SQL_ATTR_METADATA_ID statement attribute was set to SQL_TRUE, and the SchemaName or ColumnName argument was a null pointer.
For SQLColumn, SQLColumnPrivileges, SQLProcedures, SQLProcedureColumns and SQLSpecialColumns, the SQL_ATTR_METADATA_ID statement attribute was set to SQL_TRUE, the CatalogName argument was a null pointer, and the SQL_CATALOG_NAME InfoType returns that catalog names are supported.(DM) The SQL_ATTR_METADATA_ID statement attribute was set to SQL_TRUE, and the SchemaName, ProcName, or ColumnName argument was a null pointer.
Attribute cannot be set now
This Informix ODBC error code is the same as SQLSTATE value HY011. The following functions can return this error code: SQLBulkOperations, SQLSetConnectAttr, SQLSetEnvAttr, SQLSetPos and SQLSetStmtAttr
For SQLBulkOperations and SQLSetPos, the driver was an ODBC 2.x driver; the SQL_ATTR_ROW_STATUS_PTR statement attribute was set; then SQLSetPos was called before SQLFetch, SQLFetchScroll, or SQLExtendedFetch was called.
For SQLSetConnectAttr, the Attribute argument was SQL_ATTR_TXN_ISOLATION and a transaction was open.
For SQLSetEnvAttr, a connection handle has been allocated on EnvironmentHandle. (DM) The Attribute argument was SQL_ATTR_OUTPUT_NTS, and the SQL_ATTR_ODBC_VERSION attribute had not been set.
For SQLSetStmtAttr, the Attribute was SQL_ATTR_CONCURRENCY, SQL_ ATTR_CURSOR_TYPE, SQL_ ATTR_SIMULATE_CURSOR, or SQL_ ATTR_USE_BOOKMARKS and the statement was prepared.
Memory management error
This Informix ODBC error code is the same as SQLSTATE value HY013. The following functions can return this error code: All ODBC functions except: SQLGetDiagField and SQLGetDiagRec
The function call could not be processed because the underlying memory objects could not be accessed, possibly because of low memory conditions.
Cannot modify an implementation row descriptor
This Informix ODBC error code is the same as SQLSTATE value HY016. The following functions can return this error code: SQLCopyDesc, SQLSetDescField and SQLSetDescRec.
For SQLCopyDesc and SQLSetDescRec, DescHandle was associated with an IRD.
For SQLSetDescField, the DescriptorHandle argument was associated with an IRD, and the FieldIdentifier argument was not SQL_DESC_ARRAY_STATUS_PTR or SQL_DESC_ROWS_PROCESSED_PTR.
Invalid use of an automatically allocated descriptor handle
This Informix ODBC error code is the same as SQLSTATE value HY017. The following functions can return this error code: SQLFreeHandle and SQLSetStmtAttr.
For SQLFreeHandle, the Handle argument was set to the handle for an automatically allocated descriptor.
For SQLSetStmtAttr, the Attribute argument was SQL_ATTR_IMP_ROW_DESC or SQL_ATTR_IMP_PARAM_DESC.(DM) The Attribute argument was SQL_ATTR_APP_ROW_DESC or SQL_ATTR_APP_PARAM_DESC, and the value in ValuePtr was an implicitly allocated descriptor handle other than the handle originally allocated for the ARD or APD.
Inconsistent descriptor information.
This Informix ODBC error code is the same as SQLSTATE value HY021. The following functions can return this error code: SQLBindParameter, SQLCopyDesc, SQLGetDescField, SQLSetDescField and SQLSetDescRec.
For SQLBindParameter, the descriptor information checked during a consistency check was not consistent. The value specified for the argument DecimalDigits was outside the range of values supported by the data source for a column of the SQL data type specified by the ParameterType argument.
For SQLCopyDesc, SQLSetDescField, SQLSetDescRec, the descriptor information checked during a consistency check was not consistent
For SQLGetDescField, the SQL_DESC_TYPE and SQL_DESC_DATETIME_INTERVAL_CODE fields do not form a valid ODBC SQL type, a valid driver-specific SQL type (for IPDs), or a valid ODBC C type (for APDs or ARDs).
Cursor operation conflict
This Informix ODBC error code is the same as SQLSTATE value 01001. The following functions can return this error code: SQLExecDirect, SQLExecute and SQLSetPos.
For SQLExecute and SQLExecDirect, StatementText contained a positioned update or delete statement and no rows or more than one row were updated or deleted. (For more information about updates to more than one row, see the description of the SQL_ATTR_SIMULATE_CURSOR Attribute in SQLSetStmtAttr.) (Function returns SQL_SUCCESS_WITH_INFO.)
For SQLSetPos, the Operation argument was SQL_DELETE or SQL_UPDATE, and no rows or more than one row were deleted or updated. (For more information about updates to more than one row, see the description of the SQL_ATTR_SIMULATE_CURSOR Attribute in SQLSetStmtAttr.) (Function returns SQL_SUCCESS_WITH_INFO.)
Fractional truncation.
This Informix ODBC error code is the same as SQLSTATE value 01S07. The following functions can return this error code: SQLExecDirect, SQLExecute, SQLExtendedFetch, SQLFetch, SQLFetchScroll, SQLGetData and SQLSetPos
For SQLExecDirect, SQLExecute, SQLExtendedFetch, SQLFetch, SQLFetchScroll and SQLGetData, the data returned for an input/output or output parameter was truncated such that the fractional part of a numeric data type was truncated or the fractional portion of the time component of a time, timestamp, or interval data type was truncated.
For SQLSetPos, the Operation argument was SQL_REFRESH, the data type of the application buffer was not SQL_C_CHAR or SQL_C_BINARY, and the data returned to application buffers for one or more columns was truncated. For numeric data types, the fractional part of the number was truncated. For time, timestamp, and interval data types containing a time component, the fractional portion of the time was truncated.
Invalid keyword.
This Informix ODBC error code is the same as SQLSTATE value 01S09. The following function can return this error code: SQLDriverConnect.
For SQLDriverConnect, the string in *InConnectionString contained a SAVEFILE keyword, but not a DRIVER or a FILEDSN keyword. (Function returns SQL_SUCCESS_WITH_INFO.)
A protocol error has been detected. Current connection is closed.
This Informix ODBC error code is the same as SQLSTATE value 08S01.
Connection is closed by the server. Try running the client application again.
SQLGetTypeInfo supported for FORWARD_ONLY Cursors
This Informix ODBC error code is the same as SQLSTATE value S1000. The following function can return this error code: SQLGetTypeInfo.
Change your cursor type to SQL_CURSOR_FORWARD_ONLY.
In SQLExtendedFetch, only SQL_FETCH_NEXT is supported for SQL_SCROLL_FORWARD_ONLY cursors
This Informix ODBC error code is the same as SQLSTATE value S1000. The following function can return this error code: SQLExtendedFetch.
Create and Drop database must be executed within a ServerOnly Connection
This Informix ODBC error code is the same as SQLSTATE value S1000. The following function can return this error code: SQLPrepare.
Change your CONNECTDATABASE option to YES in the connect string for SQLDriverConnect or remove this option from the connect string, as default value of CONNECTDATABASE is YES.
Syntax Error.
This Informix ODBC error code is the same as SQLSTATE value S1000. The following functions can return this error code: SQLNativeSQL, SQLExecDirect and SQLPrepare
Check your statement string for syntax error. Consult ODBC Reference Manual for SQL syntax.
The statement contained an escape clause not supported by this database driver.
This Informix ODBC error code is the same as SQLSTATE value S1000. The following functions can return this error code: SQLNativeSQL, SQLExecDirect and SQLPrepare.
Remove the escape clause form the statement string argument for the above functions.
Invalid lo_stat structure.
This Informix ODBC error code is the same as SQLSTATE value S1000. The following function can return this error code: SQLExecDirect.
Reopen the large object and then refetch the lo_stat structure.
Describe Parameter supported only for INSERT and UPDATE statements.
This Informix ODBC error code is the same as SQLSTATE value S1000. The following function can return this error code: SQLDescribeParam.
Expected number of parameters does not match parameters returned from server.
This Informix ODBC error code is the same as SQLSTATE value S1000. The following functions can return this error code: SQLExecDirect and SQLExecute.
Check the number of output parameters bound for that statement.
Database is not capable of supporting transactions. Check logging mode.
This Informix ODBC error code is the same as SQLSTATE value 01S02. The following functions can return this error code: SQLSetConnectAttr.
Any open cursors are now invalid and must be closed before being used.
This Informix ODBC error code is the same as SQLSTATE value 01000. The following functions can return this error code: SQLExecDirect, SQLExecute and SQLSetConnectAttr
Already in transaction. SPL routine could not get executed
This Informix ODBC error code is the same as SQLSTATE value S1000. The following functions can return this error code: SQLExecDirect, SQLExecute, SQLFetch, SQLFetchScroll, SQLExtendedFetch, SQLBulkOperations, SQLParamData and SQLSetPos.
Remove any redundant Begin Commit from the client application.
Cannot set LO Aotomatic option OFF when Standard ODBC Types only is ON
This Informix ODBC error code is the same as SQLSTATE value S1000. The following functions can return this error code: SQLSetStmtAttr and SQLSetConnectAttr.
Turn the SQL_INFX_ATTR_ODBC_TYPES_ONLY off first before turning the SQL_INFX_LO_AUTOMATIC_ATTR off for a statement or connection.
Cannot set Standard ODBC Types only to ON when LO Automatic option is OFF
This Informix ODBC error code is the same as SQLSTATE value S1000. The following functions can return this error code: SQLSetStmtAttr and SQLSetConnectAttr.
Turn the SQL_INFX_LO_AUTOMATIC_ATTR on first before turning the SQL_INFX_ATTR_ODBC_TYPES_ONLY on for a statement or connection.
The smart large object automation refers to the usage of accessing smart large objects using standard ODBC API. Earlier the smart large objects were accessed by the application executing the ifx_lo
Functions that were not the standard way of accessing a data type in an ODBC application. With the large object automation support the application will be able to use standard OBDC way as well as the existing way of accessing large objects.
Operations supported with this automation on smart large objects will include selection, insertion, updating and deletion. This feature will be applicable only to the smart large objects CLOB and BLOB but not to BYTE and TEXT
For inserting/updating/deleting a CLOB data type the application will bind the CLOB data type using SQLBindParameter with C type as SQL_C_CHAR and SQL type as SQL_LONGVARCHAR. Where as BLOB data type will be bound with C type as SQL_C_BINARY and SQL type as SQL_LONGVARBINARY.
Driver performs insertion of the smart large objects in the following steps.
For selecting a CLOB data type the application will bind the column's C type as SQL_C_CHAR. Whereas for the BLOB the C type will be bound as SQL_C_BINARY.
Driver performs selection of the smart large objects in the following steps.
There is a new connection and statement attribute to differentiate between the old way and the new way of accessing smart large objects. The new attribute is called INFX_LO_AUTOMATIC_ATTR. If the application enables this attribute as a connection attribute, then all the statements for that connection will inherit the attribute value. The only way to change this attribute value per statement, is to set/reset it again as a statement attribute. If this attribute is enabled for the statement then the application can access the smart large object using the standard ODBC way as described above, otherwise the application can use the old way of accessing the smart large object using ifx_lo functions. The application cannot use the ifx_lo functions if this attribute is enabled for the statement.
The INFX_LO_AUTOMATIC_ATTR attribute can also be enabled by turning on a new option "Report Standard ODBC Types" under the advanced tab of the ODBC Administration for Informix Driver DSN.
SQLDescribeCol for a CLOB datatype column should return SQL_LONGVARCHAR for the DataPtrType, whereas for the BLOB datatype column it should return as SQL_LONGVARBINARY only if INFX_LO_AUTOMATIC_ATTR attribute is enabled for that statement. Earlier versions of Informix drivers use to return as SQL_INFX_UDT_CLOB for CLOB data type and SQL_INFX_UDT_BLOB for BLOB data type.
SQLColAttribute for a CLOB datatype column should return SQL_LONGVARCHAR for the FieldIdentifier of SQL_DESC_TYPE, whereas for the BLOB data type column it should return as SQL_LONGVARBINARY only if INFX_LO_AUTOMATIC_ATTR attribute is enabled for that statement. With earlier versions of Informix driver it use to return as SQL_INFX_UDT_CLOB for CLOB data type and SQL_INFX_UDT_BLOB for BLOB data type.