Exactly how are you doing things, Bill? It isn't possible to open a
TIB_Cursor without first starting a transaction - if you don't do it
yourself, then IBO does it for you. Hence, if you start a transaction
after opening the TIB_Cursor, that either means that you have two
transactions, or that Jason has written IBO so that it knows that your
start of transaction more or less should be ignored (I've never
started a transaction after doing TIB_Cursor.First and don't know how
IBO handles this).

I normally do
TIB_Cursor.First; //This also starts the transaction if not started
while not TIB_Cursor.Eof do
<all processing>
TIB_Transaction.Commit;

If I wanted to commit more often than after finishing all processing,
I'd have two transactions, one for the TIB_Cursor and another for a
TIB_DSQL. All updates I'd then do through the TIB_DSQL and commit that
transaction after x updates (x being between 1 and about 10000).

By doing CommitRetaining I know it is possible to do "Commits" while
still retaining the position of the TIB_Cursor (CommitRetaining has
the drawback that it doesn't allow the oldest active transaction to
move forward and should be used with care). I think it is possible to
do even proper Commits and retain the position by setting some
property to RaKeepDataPos or similar, but that should be IBO mimicing
such a behaviour by closing the dataset, committing, reopening and
moving to the correct position.

Finally, if what I've written doesn't make sense, blame it on me being
tired and heading for bed ;o)

HTH,
Set

--- In IBObjects@yahoogroups.com, "Bill Gage" wrote:
>
> Is there some special rules to follow when using the TIB_Cursor when
> editing the current record and posting the changes.
>
> This is what I am running into.
>
> I open my SQL query using a TIB_Cursor.
>
> before I edit the record I start a transaction,
> set the cursor into Edit mode,
> make my changes
> Post the changes
> commit the transaction
>
> while still using the current record, I try doing the above again
> and I get the following error
>
> deadlock
> update conflicts with concurrent update
>
> How can I prevent this from happening?
>
> Bill