>
>No!!! Firebird doesn't support dirty read! The order of isolation (from
>lowest to highest, in Delphi-talk) is ReadCommitted, Concurrency and
>Consistency. You never need Consistency except when you want to "freeze"
>the state of the database for your entire operation.
>
>All you want to do here is insert new records while your reporting
>procedure looks at some *other* records. Use two transactions - both
>Concurrency or ReadCommitted, it won't matter much, since you are not doing
>any updating. There is no potential for conflict here.
>
>By using Consistency, you are making it so that your transaction blocks any
>DML, even inserts, to preserve a frozen view of the whole database. In
>fact the only thing you want to freeze is the batch of transactions from
>the last shift, which the new shift doesn't even touch.
>
>heLen

Helen,

I have a situation where different POSs (like the pumps, for example) can
start a new record or update an existing record while the shift change is
going on. So, for example, a new transaction at a petrol pump will create a
record in a table, and mark it as being in use by that particular pump.
When the financial transaction is complete (i.e., the pump has stopped
pumping, and the client pays the money), the transaction is completed and
moved to the LOG table.

This may happen while the shift change is happening.

I can figure out what to do in the Delphi code - but how would I handle
this situation with respect to transaction control?

Regards

Tim


[Non-text portions of this message have been removed]