Subject Re: TIB_Cursor Commits -- Transactions
Author Bill Gage
Then let me gain some greater understanding.
If I open a query with a TIB_Cursor and the query returns 20,000
records. And almost each line will be edited as the cursor is
scrolled through. When is the appropriate time to start a
transaction and commit the transaction. The way I have been doing
it now is.

I open the cursor and before I edit the record I start the
transaction. Then after I post the record I commit the
transaction. Is this not the right way to manage the transactions.
This method seems to work, however if there is a better or more
faster way I would love to know how.

Is there an document I can refer to for the appropriate time to
start and commit transactions? Or even some general guidelines for
using transactions?


--- In, Svein Erling Tysvær
<svein.erling.tysvaer@k...> wrote:
> Exactly how are you doing things, Bill? It isn't possible to open
> TIB_Cursor without first starting a transaction - if you don't do
> yourself, then IBO does it for you. Hence, if you start a
> after opening the TIB_Cursor, that either means that you have two
> transactions, or that Jason has written IBO so that it knows that
> start of transaction more or less should be ignored (I've never
> started a transaction after doing TIB_Cursor.First and don't know
> IBO handles this).
> I normally do
> TIB_Cursor.First; //This also starts the transaction if not
> while not TIB_Cursor.Eof do
> <all processing>
> TIB_Transaction.Commit;
> If I wanted to commit more often than after finishing all
> I'd have two transactions, one for the TIB_Cursor and another for
> TIB_DSQL. All updates I'd then do through the TIB_DSQL and commit
> transaction after x updates (x being between 1 and about 10000).
> By doing CommitRetaining I know it is possible to do "Commits"
> still retaining the position of the TIB_Cursor (CommitRetaining
> the drawback that it doesn't allow the oldest active transaction
> move forward and should be used with care). I think it is possible
> do even proper Commits and retain the position by setting some
> property to RaKeepDataPos or similar, but that should be IBO
> 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
> tired and heading for bed ;o)
> HTH,
> Set
> --- In, "Bill Gage" wrote:
> >
> > Is there some special rules to follow when using the TIB_Cursor
> > 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
> > and I get the following error
> >
> > deadlock
> > update conflicts with concurrent update
> >
> > How can I prevent this from happening?
> >
> > Bill