18 replies to this topic

[Richard Bassett]

If, as you have determined, there IS an active transaction at the point you are trying to rollback (ie. database work was done in the global function(s) and not committed) then ProIV not honouring the rollback is clearly a bug. Just confirming that I agree

I think it would be OK in principle for ProIV to not issue an actual rollback when it KNOWS FOR SURE that no transaction has been started since the last commit - but it seems a fairly pointless optimization in practice.

Of course whether ProIV REALLY knows this or not can be pretty debatable if for example one's app included C code linked with the kernel which does database work. Really you would need a way to declare that to ProIV.

I was only saying it was ARGUABLY desirable because I was assuming the global function(s) had been committed, thereby shortening transaction (and hence lock) durations. This is generally considered a 'good thing' but perhaps (I agree with Shaun) it can equally often not be what you want.

Cheers, Richard

[Dan Shannon]

I would suggest that it's very bad practice to commit in a global function in any case - you're committing any work you've done in calling functions, and if you're setting SQL_TRANSACTION_ERROR (which is desirable in itself) then it prevents you from having any rows locked / open FOR UPDATE cursors in the calling function. Global functions shouldn't do this - they're not globally re-usable if they do!

[Richard Bassett]

Hi Dan,

I wasn't suggesting comitting global functions unilaterally/explicitly – that's clearly a bad idea unless for some reason you want to forcibly prevent there being an outstanding (non-read-only) transaction when the global function is called. As you point out, any such 'enforcement' only works on Oracle if people have set SQL_TRANSACTION_ERROR as they should

I was suggesting it was potentially OK for a global function to be automatically committed when there is NO transaction extant in the current (stack of) calling function(s).

I think maybe you are thinking specifically of situations where all transaction boundaries are static and explicit. This would certainly be the case if, as I have seen you recommend, ProIV automatic commit processing is suppressed.

I don't disagree with you that ProIV's 'automatic, dynamic' transaction boundaries sometimes leave a bit to be desired – but I think there is value in the idea of a dynamic, optimizing 'model' which (idealistically at least) requires less understanding and coding on the part of the programmer.

Cheers, Richard

[Arnold Mulder]

I Agree with Dan ... we have also had to put in a 'dummy' Oracle file if a parent function calling a global function with Oracle files did not have a Oracle file. This is fine for identify during a conversion and patching with the dummy file, but sure leaves something desired for ongoing programming and expecting your programmer to remember!