Hi there
the point is that allowing transaction control commands in the EXEC/EXEC IMMEDIATE syntax is not proper language support for these commands and renders the overall transaction handling inconsistent.
For example: usually (if not in auto commit mode) you can always run a rollback after calling a procedure and everything will be as it was before.
With using commit/rollback within a procedure that's not the case at all.
In fact you cannot know what will be committed or rolled back which makes life suddenly a lot more complicated.
Up to now the only use case I have seen requiring transaction control in SQLScript is managing data loads. And again often the scenario for that was to build a data warehouse-like data mart.
The problem with that is: currently SQLScript is language wise insufficient for this kind of application.
For the smallest things (think error logging and handling) huge workarounds need to be implemented.
There is no reasonable scheduling option available and no way to run multiple tasks/procedures in parallel and manage these tasks.
It boils down to a huge list of workarounds and the inevitable use of external tools (or the reduction of functions in the system).
Now, given this situation, as a vendor for data processing platforms as we are, doesn't it make sense to say: let's concentrate functionality in the tools that are made for this kind of requirement and keep the other tools simple and lean?
I think it does.
and again - that's what I think - not the official SAP line in any way.
- Lars