I think it sounds like a good idea - especially since you may want your
report transaction to have tiConcurrency isolation (ignore changes made
after the report started), whereas your editing may prefer itCommitted (see
changes once they are committed).

I think there is more work to do with a rollback than with a commit, so I
always commit readonly transactions. But I don't know how much difference
it makes, probably not enough to make it a high priority to change already
existing code.

Set

At 23:15 13.11.2002 +1100, you wrote:

>I thought I had a smart idea recently and set all my report queries to their
>own connection/transaction and set the transaction to read-only... thinking
>that this might improve performance, reduce the chance of transaction
>conflicts etc...
>I suddenly started getting no wait transaction deadlocks... took me a while
>to realise that it was the report transactions. I set them all to rollback
>when the report was finished or cancelled and all was fine again.
>I wonder now... with a read-only transaction... is it better to rollback or
>commit them after I'm done with them? Or does it make absolutely no
>difference?