Subject | Re: [IBO] Re: TIB_Cursor Commits -- Transactions |
---|---|
Author | Lester Caine |
Post date | 2005-02-17T18:56:28Z |
Bill Gage wrote:
one at a time to the client? The proper way to do this would be to
create SQL to do the job on the server.
manually updating 20000 records one at a time, then a commit after every
entry might be fine. If you are reading and automatically processing the
data, then a start before the batch and a commit at the end would be fine.
order with hundreds of line items, then you might want to start a
transaction and not commit until the whole order is entered. Any
problems any you can roll back to the start. 20000 records, I would
expect manual data to be perhaps 30 or 40 records on a page of hard
copy, so you would process each page and then commit. IBO will handle
the times it needs to open a new transaction automatically, and
'refresh' that via timeouts to prevent problems on the server, so
'interfering' more than necessary will just mean that you may get the
best performance.
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services
> Then let me gain some greater understanding.If you are processing 20000 records do you need to bring them all back
> 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.
one at a time to the client? The proper way to do this would be to
create SQL to do the job on the server.
> I open the cursor and before I edit the record I start theAgain we need to know what you are doing to the record. It you are
> 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.
manually updating 20000 records one at a time, then a commit after every
entry might be fine. If you are reading and automatically processing the
data, then a start before the batch and a commit at the end would be fine.
> Is there an document I can refer to for the appropriate time toThis really is just a matter of a unit of work. If you are possessing an
> start and commit transactions? Or even some general guidelines for
> using transactions?
order with hundreds of line items, then you might want to start a
transaction and not commit until the whole order is entered. Any
problems any you can roll back to the start. 20000 records, I would
expect manual data to be perhaps 30 or 40 records on a page of hard
copy, so you would process each page and then commit. IBO will handle
the times it needs to open a new transaction automatically, and
'refresh' that via timeouts to prevent problems on the server, so
'interfering' more than necessary will just mean that you may get the
best performance.
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services