At 09:55 PM 10-12-02 -0800, you wrote:

>Now, assuming that I have all that correct, and am now using the correct
>terminology, let me ask my questions:
>
>1) Consider the following sequence of events:
>Client A starts a transaction.
>Client B starts a transaction.
>Client A posts an INSERT statement, using key 'ABCD'
>Client B posts an INSERT statement, using key 'ABCD'
>Client A commits it's transaction.
>Client B commits it's transaction.
>
>At which point does the Key Violation occur? Is it when Client B posts
>it's INSERT statement, or when it commits it's transaction?

When Client B attempts to commit its transaction. (It will fail - nothing
in the transaction will be committed.)

>2) Now, consider this slightly different sequents of events:
>Client A starts a transaction.
>Client B starts a transaction.
>Client A posts an INSERT statement, using key 'ABCD'
>Client A commits it's transaction.
>Client B posts an INSERT statement, using key 'ABCD'
>Client B commits it's transaction.
>
>In this case, does the Key Violation occur when Client B posts it's INSERT
>statement, or it not happen until it commits it's transaction?

You've got it now. It occurs when Client B posts its INSERT statement.

>3) Final case:
>Client A starts a transaction.
>Client A posts an INSERT statement, using key 'ABCD'
>Client A commits it's transaction.
>Client B starts a transaction.
>Client B posts an INSERT statement, using key 'ABCD'
>Client B commits it's transaction.
>
>Same question as before.

Same answer. IOW, starting a transaction doesn't do anything except start
a context. Even if both transactions SELECT the identical dataset and open
it in the client app in EDIT mode, still there is nothing blocked to either
reader. The server simply doesn't know what is happening in the client.

If you use IBO's PessimisticLocking property, what happens is that, as soon
as the user changes anything on a record (edits, deletes), the client sends
a dummy update across to the server. That then locks that row. If client
B then proceeds to do something to the the same row, its request to edit
will fail because of Client A's lock, and IBO will prevent that row from
being edited.

Inserts, you'll realise, are different. Because they are both new, and
don't know about each other, there is no "current recversion" which the
server can refer to; so nothing barfs until the conflict situation
actually exists.

Helen