And I want to thanks Jason for implementing this :) I was requesting
this feature for a long time, and had being using it for the last 2
months with no problems.

SL> There is only one awkward aspect left I have not fully decided how to deal
SL> with. When doing a full refresh of a dataset that has an active
SL> IB_TransForUpdate transaction, it will not see the non-committed changes.
SL> The resolution could be to cause the refresh to occur within the
SL> IB_TransForUpdate context or to raise an exception. I'd be interested in
SL> hearing what others think on this subject.

Well, in my case, calling refresh while TransForUpd is active will
never happen, and I can't think about any scenario where such "logic"
would be used :) The updates are usually very fast and short. I guess
raising an exception is the safest thing to do.

[]s
Carlos H. Cantu
www.FireBase.com.br - www.firebirdnews.org
www.warmboot.com.br - blog.firebase.com.br

SL> Thomas,

>> Hello Jason,
>>
>> >> One thing is, if you only read data, then use a read-only transaction.
>> >> In combination with the read committed isolation level, you are in a
>> >> transaction mode with very low overhead and OIT/OAT won't get stuck as
>> >> well, even for long runners.
>> >
>> > It might also be helpful to make use of a relatively new feature I added
>> to
>> > IBO that enables you to separate your transaction handling between two
>> > physical transactions. One is for reading only and the other is for your
>> > updates and individual record synchronizations. The new property is
>> called
>> > IB_TransForUpdate.
>>
>> Thanks for letting me know.

SL> This property was requested by Carlos Cantu so that when using cached
SL> updates it was possible to have different transaction isolation and behavior
SL> between the fetching of records and the processing of the updates. I chose
SL> to implement it the way I did so that you could also take advantage of this
SL> through other more direct means.

SL> Because Firebird has enhanced the transaction behavior internally such that
SL> ReadCommitted and ReadOnly transactions do not stuff up garbage collection
SL> and bloat the internal transaction buffers, it is now possible to have all
SL> fetching be performed through such a transaction while all of your updates,
SL> etc. are performed using a transaction that can fully commit without
SL> interfering with open cursors that have not yet fetched all records in your
SL> dataset.

SL> Thus, between the enhancements in Firebird and the enhancements in IBO, you
SL> can now have full fluidity and efficiency in interacting with your data such
SL> that large datasets and updates are no longer in conflict.

SL> Also, the most difficult aspect of this is keeping records in sync. No other
SL> component set resolves this for you (at least not to my knowledge) to get
SL> record-level synchronization when you are using different transactions for
SL> reading and writing. IBO automatically detects when a transaction for
SL> updating is active and it distinguishes record synchronization from normal
SL> fetching and handles the record synchronization via the transaction being
SL> used for updates so that you will always get the latest version of records
SL> when reading them.