Hi.

We have a baan standard session with source code. In the Debugger, I can see a very strange behavoiur:

1. db.retry.point()
2. ...
3. db.insert() --> data can be seen in the database!?
4. ...
5. other db.insert() --> data can be seen in the database!?
6. ...
7. abort.transaction() --> now the data from 3 and 5 disappear

I would have bet that this cannot be achieved. Any ideas / explanations / hidden global settings that allow this?

Regards
Günther

Hi Günter,

don't have a real informix knowledge but according to an old Baan "Technical Reference Guide for Informix Database Driver" can happen when the Informix driver uses dirty read isolation.

Regards,
Jürgen

Thanks Jürgen.

Maybe I should have posted "data can be seen in Baan standard applications" instead of "data can be seen in the database".

You see my problem? Normally, only after a commit.transaction() I can see the data.

But the funny thing about this, abort.transaction() does "remove" the data correctly.

Regards
Günther

I am not sure I get the question. To me this is a normal thing. The transaction starts with a db.retry and would end with a commit transaction. The abort transaction means everything from the retry point to the abort transaction is backed out. Until I read the second post I was going to ask how you saw it in the database without a commit of some sort.

H Mark,

okay, my Explanation was not very clear, sorry. The problem is: I see data in a Baan standard session before(!) a commit.transaction(), right after a db.insert(). Never seen that before.

Regards
Günther

The scenario is not happening at my Server here, Oracle,i.e, Displaying the new value in UI before commit is hit.

Hi Günter,

OK, but your Baan Session will only show the data based on what is returned by the DB, so for me it's not a problem in Baan. The source of the problem should be your Informix DB.

Regards,
Juergen

Gotcha now - I get it. Informix used to have something around dirty reads. They basically let you see the data before it was committed. I did google something like this "However, a program that uses ANSI Read Uncommitted or IBM Informix Dirty Read isolation sometimes reads updated rows before the updating program ends its transaction. If the updating program later rolls back its transaction, the reading program processes data that never really existed (possibility number 4 in the list of concurrency issues)." It seems to me there used to be a setting around this for Informix - but it has been over 20 years since we used that so not really sure what it was. Maybe if you have 2 databases acting in different ways you can compare the setups or init parameters.

Hi Mark,

thanks a lot for your efforts. The setting in Informix dbaccess scripts is "set isolation to dirty read;", that's true. But I've never seen this effect in Baan sessions before. It's not really a problem, because everything works fine after all. The only thing: I would like to understand what's going on ...

Thanks a lot
Günther