Jeroen wrote: > Granted, that's probably going to force the issue. I do wonder though: > one of the arguments in favour of the current semantics is that the > problems can be worked around using nested transactions. Then what were > people doing before nested transactions, in Tom's scenario where the > programmer doesn't know where transactions begin?
The trick is that with the current semantics, you don't have to watch transaction activity, just the prepare statements. You know if and when (from the client/driver's point of view) a prepared statement exists because you created it and don't have to be concerned about the lifetime. If you guys change the lifetime, it becomes difficult or impossible to set a flag on the client which guarantees prepared statement existence. This means I have to wrap the statement execution with a subtransaction or run the risk of bouncing a current transaction. Currently in the applications I write 70% of all I/O goes through prepared statements...the reason to do this was to reduce statement turnaround latency, which is the main driving performance factor in COBOL applications. I would be fine with changing the lifetime if an EXECUTE failure did not abort the current transaction. Then I could simply watch the return code of the statement execution and prepare the statement on demand...from my point of view, this would actually be the most elegant scenario. Merlin ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])