Thanks for that Helen, as informative as always. Now then, where to
begin....

My application could have multiple users all viewing/editing the same
record. I don't want to lock users out by using pessimistic locking
so it looks as though concurrency isolation is what I need.

I noticed you said "....after data is posted but before it is
committed". Generally, in my app's dialogs when the user presses OK,
I do the following:

// other stuff
If ( query->Modified )
Query->Post()
Query->IB_Transaction->Commit();

i.e. there is no delay between the Post and commit.

> >I had expected that when app2 committed it's changes,
>
> You said app2 didn't do any changes. But, even if it had, it

wouldn't

> cause an exception in ReadCommitted, since app2 would already see

app1's

> changes before it posted. The only time you'll get an exception

with

> ReadCommitted is if app2 is in a RecVersion False transaction and

tries to

> *post* when another transaction has already posted (but not

committed) and,

> in so doing, created a new record version that is newer than the

last

> committed version. (Or if the other transaction deleted the row,

of course

> - then you get an exception of a different sort...row was not

located to

> update...)

This confused me:

> >can the App2 TIB_Query tell me if the row has been changed

elsewhere,

>
> The changes won't appear in the client buffer until you refresh,

but the

> transaction knows about the latest committed version as soon as it

commits.

>
> >or do I need to refresh the row?
>
> Refreshing the row doesn't make any difference to what the

transaction can

> see. Looking at it from the client side, the buffer only knows

about

> changes done to itself. You can change this situation by setting
> BufferSynchroFlags to have the buffer synch up with the server at

certain

> points (one or more). It still won't help if your app already

changed what

> was in its buffer. If you want a more reactive response to

external

> changes, use DMLCaching.

If App2 changes the data, posts and commits. I take it that App1 can
see the data if it does a refresh (whilst still in a transaction).
Can I take it that even if App1 has change some data (but not posted
& committed) a refresh will also see App2's changed data?

For "potshot" editing of records, it seems that I have a choice
between:

ReadCommitted: Where I need to know if I'm over-writing a newer
record before committing. Ether I can do a refresh and compare the
data, or use a trigger incremented `generation Id' as part of the PK,
in which case the update will fail. Or, an update trigger on the
table could signal an event which would cause the dialog to refresh
the row.

Concurrency: Forget about refreshing, just post and commit the
changes and catch any exception should a newer record exist and offer
to show the user the new data or overwrite with their data.

I think I need to experiment a little.

Thanks for your help.

David