jim, January 30, 2006 - 9:36 pm UTC
Hopefully, he doesn't mean that the client controls the transaction in the sense that the client does the rollback by issuing sql statements to undo the transaction. (eg Siebel does this) vs issinging the rollback statement and having the server do the rollback.
January 31, 2006 - 1:59 am UTC
I mean the client issues rollback or commit.
But if you submit a block like:
begin
proc1;
proc2;
commmit;
end;
and either of proc1, proc2 or the commit fails - the transaction is automagically rolled back by the server.
Result
Totu, January 31, 2006 - 3:15 am UTC
Thanks Tom.
So, you advice me to control transaction at client side, no need for "commit" or "rollback" statements at Server side (f.e: inside database procedure).
Another question:
Assume that I have procedure inside database:
proc1:
(emp_id number, newsal number)
update emp set salary = salary + newsal where empid = emp_id;
So, I have following code at client side:
try
Conn.BeginTransaction;
Call proce1(12, 1500);
commit;
except
rollback;
end;
Question: Can proce1 work be managed from transaction that started from client side?
Thanks in advance.
January 31, 2006 - 4:01 am UTC
yes, it is just a "statement" as far as we are concerned - and it will be executed atomically (the procedure either succeeds entirely or fails entirely). And the client has the ability to commit the work done by it, or roll it back.