Bug while fetching rows in OnLine 5.0

There seems to be a bug in OnLine that affects whether rows can be fetched depending on the isolation level used. We have an ESQL/C program which opens a cursor and starts fetching rows. If a fetch fails because the row is locked, the program changes isolation level from COMMITTED READ to DIRTY READ and tries the fetch again. After fetching the locked row, we change the isolation level back to COMMITTED READ and continue. The reason we do this is that we do not want to be held up by locked rows, but we do want to be able to identify phantom rows. The problem is that if there are two locked rows and they are either adjacent or adjacent but one, the program is forced to change isolation levels for the first row but not the second. In other words, the second locked row is being successfully fetched with an isolation level of COMMITTED READ, which should not be possible. It does not make any difference if the rows have the same home page or not. When rows that are more than two rows apart are locked, the program behaves as expected and changes to DIRTY READ for both locked rows. My questions are: 1. Is the ability to switch between isolation levels while a cursor is open and change the effect of fetches expected and supported behaviour? 2. Is this a known bug? If so, what version of OnLine is it fixed in? If not, when will it be fixed? Is there a work-around? I've asked the local Informix office these questions and haven't had any response as yet. The relevant versions are: OnLine 5.00uC3, ESQL 5.00.UC2 on SunOS. Any help is much appreciated. -- /~~` /~~\\ /~~` /| /| /| Stephen Szalla sms@mel.cocam.oz.au | | |-| /-| / | / | Co-Cam Computer Group Tel: +61 3 286 3456 \\__, \\__/ \\_ / |/ |/ | Melbourne, Australia Fax: +61 3 417 7857