Re: Is This Behavior Documented?

M. Livenspargar wrote: > > And if so, where?? > > I have a table with one column of datatype serial. The table has 2 > rows when I execute the following SQL in DBAccess: > > set isolation to committed read;> begin work; > insert into table1 values (0); > select count(*) from table1;> rollback work; > > The 'select count(*)' line returns a value of 3. After this code has > executed, a 'select count(*)' returns a value of 2, just as I would > expect. > > Why does the select in the code given return a value of 3 when the > isolation level is set to committed read and there are two committed > rows and one uncommitted row? I assume it is because the same process > that issued the insert is doing the select. Is this an > implementation-dependent feature, a rule, or a bug? I'm running > v7.11.x of the engine. > > Thanks for your help, > M. Livenspargar Well, I guess this IS a rule, because 'commited read' takes effect when and only when you try and access a row locked by someone ELSE than you. So, when you are in YOUR session, everything YOU do seems to be commited from YOUR session's point of view. All right ? Bye. Valery