Mahesh Ishwar wrote:

>I've .NET application for which I'm using Firebird .NET provider. In my code I'm have an Insert statement, which succesfully executes. But if I've a session of Firebird already open, the changes of insert are not reflected when I do a select for that inserted record. If I exit from my session, and try a'ain, I'm able to get the data.
>
>But for a realtime application this doesn't makes sense to exit session a'ain & a'ain. This is happening even when I commit from my code. Has anyone come across this sort of problem, 'n if yes is there any solution?
>
>

Welcome to transactions. One of the attributes of a transaction is
consistency, meaning that when you read the same data set twice, you get
the same answer. Seems like a good thing. However, that does mean that
you don't see changes. Hmmm... there is some logic there. If I always
see the same view of the data within a transaction, I don't see
changes. OK. Other systems - lock based systems - either fail to
deliver consistent reads or prevent other transactions from changing a
record set which has been read. If your other session had counted the
records in the table you tried to insert to, your insert would have
stalled until the first session ended.

Firebird provides an inconsistent read mode for those who'd rather have
the latest news than a consistent view of data. It's called
read-committed. A better solution, I believe, is to limit your
transactions to the length of time for which you need a consistent view
of data.

Regards,

Ann