Subject | Re: RE: [firebird-support] Commit Retaining Transactions |
---|---|
Author | Pavel Menshchikov |
Post date | 2005-08-02T13:14:54Z |
Hello,
BW> the current cursor position? Have you considered saving that record key
BW> and locating it (after commit and reopen the query)? Obviously this
BW> isn't the best solution in all cases, but we've found it to work very
BW> well in some.
Brenden, I guess this method has to re-fetch at least all rows to the
book-marked one (after re-opening), and that's not good in many cases.
Ruaan, you could use long-lasting *read-only* read-committed
transaction and another short-lasting writing transaction to modify
your DB.
--
HTH
Best regards,
Pavel Menshchikov
http://www.ls-software.com
>> I am trying to find the best solution for a long running transaction.BW> I'm presuming that you don't want to commit so that you're not losing
>> What would be the best solution of the 2 methods I describe
>> and why or why not?
>> 1] Use 2 transactions - one for read and one for write and
>> commit the write transaction every 100 records or
>> 2] Use 1 transaction with CommitRetaining every 100 records
>> and a hard Commit at the end.
>> Any other suggestions would also be welcome
BW> the current cursor position? Have you considered saving that record key
BW> and locating it (after commit and reopen the query)? Obviously this
BW> isn't the best solution in all cases, but we've found it to work very
BW> well in some.
Brenden, I guess this method has to re-fetch at least all rows to the
book-marked one (after re-opening), and that's not good in many cases.
Ruaan, you could use long-lasting *read-only* read-committed
transaction and another short-lasting writing transaction to modify
your DB.
--
HTH
Best regards,
Pavel Menshchikov
http://www.ls-software.com