Informix Online Documentation |
Date: 10/15/99
Version: 9.30
The purpose of these release notes is to make you aware of any special actions required to configure and use INFORMIX-ESQL/C on your computer. This file also describes new features and feature differences from earlier versions of this product and other Informix products, and how these differences affect current products. In addition, this file 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-ESQL/C Programmer's Manual which provides thorough information about product features and behavior.
These release notes are written for the following audience:
Version 9.30 of INFORMIX-ESQL/C has been tested with the following database server configurations:
INFORMIX-ESQL/C includes source code files for many of the examples in the INFORMIX-ESQL/C Programmer's Manual. The installation process copies these source code files into the following directory:
For more information about the example files for INFORMIX-ESQL/C, see the Introduction to the
INFORMIX-ESQL/C Programmer's Manual.
Decimal precision for FLOAT and SMALLFLOAT conversions to DECIMAL data type has been increased from 8 (SMALLFLOAT) and 16 (FLOAT) to 9 and 17, respectively.
The functions deccvflt() (SMALLFLOAT to DECIMAL conversion) and deccvdbl() (FLOAT to DECIMAL conversion), which have converted float numbers to decimal numbers with 8/16 digit precision, now have 9/17 digit precision.
For example, if the C constant 123.4 is assigned to a C float variable, its binary representation is equivalent to 123.400001525....
Before the change, the following function call will generate the decimal number 123.4 as, in its binary representation, the 9th digit is 1 which does not have any rounding effect on the 8th digit.
After the change, the same function call will generate the decimal number 123.400002 as the number 5 in the 10th digit is rounded into 1 in the 9th digit.
As another example, assume the C constant 8788888.88 is assigned to a C double float variable. The binary representation of 8788888.88 is equivalent to 8788888.880000000819. Before the change, the following function call would generate the decimal number 8788888.880000001 as, in its binary representation, the 17thdigit is 8 which is rounded into 1 in the 16th digit.
After the change, the same function call will generate the decimal number 8788888.8800000008 as the 18th digit is 1 and does not have any rounding effect on the 17th digit.
You might experience differences in decimal precision after FLOAT/SMALLFLOAT to DECIMAL conversions.
The rationale for this change is that when a binary IEEE 4-byte floating-point value is converted to the closest eight-digit decimal number, or an 8-byte floating-point value is converted to the closest sixteen-digit decimal number, it is not always possible to uniquely recover the binary number from the decimal one. However, if nine decimal digits are used for the 4-byte floating-point value (and seventeen decimal digits for the 8-byte floating-point value), then converting the decimal value to the closest binary number will recover the original floating-point number.
A 9/17 client product is either CSDK 2.30 or CSDK 2.30+. A 9/17 server product is an Informix database server version 9.20 or 9.20+.
When an 8/16 client product is used with a 8/16 server product, no change in precision will occur.
When a 8/16 client product is used with a 9/17 server product, precision change will only occur in the server. The client functions, such as deccvflt() and deccvdbl(), when invoked in the client space, will still use 8/16 precision to do the conversion.
When a 9/17 client product is used with an 8/16 server product, precision change will only occur in the client. The client functions, such as deccvflt() and deccvdbl(), will use 9/17 precision to do the conversion.
When a 9/17 client product is used with a 9/17 server product, precision change occurs both in the client and the server. In particular, the client functions, such as deccvflt() and deccvdbl(), will use 9/17 precision to do the conversion.
There might be an implicit float to decimal conversion (using deccvflt() or deccvdbl()) when transporting smallfloat and float data types between client and server on heterogeneous platforms. This implicit conversion is done on all current combinations of clients and servers (for cross platforms) except the Client SDK versions 2.30 and 2.40 with Informix Dynamic Server.2000 (9.20).
A workaround has been provided in all 9/17 client products. A new environment variable IFX_USE_PREC_16 can be used to revert the precision to 8/16 for all SMALLFLOAT/FLOAT to DECIMAL conversions in the client space. Note that this environment variable affects only the client and is not sent to the server.
When IFX_USE_PREC_16 is set to 1, a 9/17 client product will only use 8/16 precision to perform all SMALLFLOAT/FLOAT to DECIMAL conversions.
A new environment variable, IFX_NOZEROMDY, has been added to change the default behavior of the DATE data type and several ESQL/C date related library functions. If IFX_NOZEROMDY is not set (the default), the date value 00/00/0000 (with 4 digit year) is accepted as a null date when it is used in a DATE data type or as input to the ESQL/C library functions rdefmtdate() and rstrdate(). The function rmdyjul() also treats the input date as a null date if all 3 fields in the mdy input array are all zeros. If IFX_NOZEROMDY is set to 1, the date value 00/00/0000 and mdy input array fields of all zeros will be treated as an invalid date.
For example, the following insert statements and error codes demonstrate the default behavior:
Notice that for the last insert statement, in which the mm/dd/yyyy values are all zeros (year having 4 zeros), no error code is returned. The date in this case is valid and treated as a null. The new environment variable IFX_NOZEROMDY changes this default behavior as follows:
Instead of treating the date value as a valid null date, a 1206 error is returned. This change only applies to zero dates having a 4 digit year.
To change the default behavior to return an error for a zero date, set IFX_NOZEROMDY to 1 on UNIX as shown in the following example:
setenv IFX_NOZEROMDY 1
On Windows, use the setnet32 utility to set IFX_NOZEROMDY to 1.
Note: This environment variable does not affect treatment of dates in a DATETIME data type or date value of '00/00/00' in which the year portion is 2 digits.
When using the Client SDK the new environment variable IFX_NOZEROMDY will change the default behavior of the date value input for the library functions only. To also change the date datatype behavior when using sql statements please check your server release notes or your manual to see if IFX_NOZEROMDY is supported for your release.
This release of INFORMIX-ESQL/C implements support for non-ANSI datetime formats, which enables both ESQL/C programs and the database server to convert them correctly.
For a complete description of this feature, refer to the INFORMIX-ESQL/C Documentation Notes for this release.
Support for Non-ANSI Datetime formats introduces a new environment variable: USE_DTENV.
To prevent the problem of backward compatibility this release of ESQL/C provides a new environment variable, USE_DTENV, to activate this feature. When USE_DTENV enables support of Non-ANSI datetime formats, both the ESQL/C program and the database server will expect and produce datetime strings in the format specified by the following environment variables, in order of precedence:
This release includes a new ESQL/C library function, ifx_var_freevar(), which prevents memory leaks by freeing the memory that has been allocated for var binary or lvarchar pointer host variables. See the Documentation Notes for a complete description of ifx_var_freevar() and related documentation.
When $deallocate collection fails because a cursor on the collection is still open, error -9984 is returned. See bug number 118211 under Fixed Problems for more information.
This section describes the known problems with this release of INFORMIX-ESQL/C and explains how to work around these problems, if possible.
113792 | MDY() returns wrong ming-guo year if year is input as ming-guo when DBDATE-DMY4/C1 |
115484 | A statement prepared during second service call in a global transaction gives error -410 if executed later. (This is not PTS 80685.) |
This is due to a previous, erroneous bug fix and will be fixed in a later release. Prepared statements are not being treated as global when used with XA. That is, a statement prepared in an XA transaction cannot be seen when in another XA service block (i.e., one with a different XID or when 'join'ing with the same xid) or when outside of an XA service block.
In the mean time, a work around is to prepare the statement again (using a different statement name) where it is to be used. In other words, if a statement had been prepared inside block xid1 but was needed in a local transaction, it must be re-prepared in the local transaction (i.e., following an xa_end(TMSUCCESS)). Similarly, if a statement had been prepared in the block identified by xid1 but it is needed in the block identified by xid2, it must be re-prepared inside of block xid2 (and xid3 . . .). The final case is where an XA transaction is 'join'ed. A statement prepared elsewhere must be re-prepared before it can be used.
Note that the statement does NOT have to be re-prepared before each use, merely before use in a different XA service block or before use outside of XA.
Some rather contrived examples to demonstrate:
Example 1:A statement prepared inside an XA transaction is not available once you leave that transaction unless it is re-prepared.
After calling xa_end(TMSUCCESS), a statement prepared inside that service block must be re-prepared before use.
A statement prepared in one XA service block must be re-prepared before use in another service block.
115397 | Executing in a global transaction, a statement prepared outside of this transaction leads to PREPARE/EXECUTE/RELEASE of the statement. This is a major performance issue. |
Cursors are sometimes re-prepared internally. This will be addressed in a future release. In the mean time, there is no work around.
117794 | Execution of a statement prepared in another XA transaction may fail with error -201 (Syntax Error). |
This problem is affected by a bug-fix in this release. It no longer returns -201 but instead returns -410 in a manner similar to the above. See above for work around.
The following problems have been fixed since the 9.21 release.