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?

Bill





--- In IBObjects@yahoogroups.com, Svein Erling Tysvær
<svein.erling.tysvaer@k...> wrote:

>
> 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