> OK, so technically, there is no reason why commit/rollbacks are not
> supported in SP, it's just a decision that was made not to allow it?

It is not "just decision". Doing commit/rollback inside SP simply makes no sense.

Each command in SQL executes inside transaction.
Client application controls what is happening inside transaction, you can
-start transaction
-execute one command
-execute another command
-rollback
If the second command was SP and executed Commit itside,
than client would not be able to rollback whole transaction.

Each command is performed as atomic, SP is also command.
If e.g. SP executed commit, but client appliaction executed rollback,
only half of the work of SP would be stored in database. Nonsense.

If you could commit inside SP, in which transaction would run
the rest of SP ? And what would happend to client that now have
invalid handle to transaction ?

You need to realize that SP _is_ command. It must behave
as _single_ command, it can't be split by commit/rollback.

What you have probably in mind is some kind of macro or script
run on server, right ?

Ivan