Description: ------------ fetchRow for Informix starts at 1, rather than the expected 0. Code has been written that anticpates this behaviour, and adjusts for it. The latest version of DB (1.6.0) corrects for this behaviour and breaks backward compatibility with existing programs. Reproduce code: --------------- /* MySQL fetches rows beginning from 0, Informix starts at 1 */ if ($dbengine=='ifx') { $iRowOffset++; } if ($iRowTotal) { $res = $dbh->limitQuery($sql, $iRowOffset, $iRowLimit); } $row = $res->fetchRow(DB_FETCHMODE_ASSOC, $iRowOffset); Expected result: ---------------- Without the adjustment to the row offset, then the first two rows that are retrieved are the same. With the adjustment, the correct rows are returned.

Just to make sure what your'e saying... Your scripts already accounted for the ifx starting row number and that combining those workarounds with the changes in 1.6.0 cause your scripts to break?

My scripts currently compensate for the older behaviour and will break if I update to the latest DB. I can change my scripts, but I would have a different problem if the script ran on an older version of DB. Since I can't always control the DB version on all production systems, I need a way to determine the version and handle it that way (preferred), OR have an option to maintain backward compatibility as Lukas suggested.

The old behavior was a bug. The new behavior creates the desired consistency between DBMS's. A way to identify the package version is a good idea. I don't think there is a direct one there now. But, your scripts could check if "defined('DB_PORTABILITY_NULL_TO_EMPTY')." If it is, you're running 1.6.0. A compatibility flag wouldn't solve the problem, since the flag wouldn't exist in old DB versions so trying to set it would cause an error. Thanks.