ExecprocEx does not autocommit?
Posted: Thu 18 Jul 2013 13:15
Hello, an other problem (or question).
We tried to use the TOraSession's ExecprocEx method. It works fine, but as I see, it does not commit, however the OraSession's AutoCommit property is set to true. Clearly visible, that table locks remains in the database after a stored procedure call. But before, we didn't used the ExecProcEX, but we used a TOraStoredProc component, and it committed the changes to the database.
It is a problem for us.
We are using Delphi 2010, and the newest ODAC 9.0.2
I've tried with a very small test application, even ExecSQLEx does the same.
The mydebug table remains locked until I quit the application (or I commit explicitly, but my test application has only this button click method, so I must quit)
The only solution is, (luckyli the ExecProcex is virtual), to encapsulate the inherited method call with commit rollback statements.
We tried to use the TOraSession's ExecprocEx method. It works fine, but as I see, it does not commit, however the OraSession's AutoCommit property is set to true. Clearly visible, that table locks remains in the database after a stored procedure call. But before, we didn't used the ExecProcEX, but we used a TOraStoredProc component, and it committed the changes to the database.
It is a problem for us.
We are using Delphi 2010, and the newest ODAC 9.0.2
I've tried with a very small test application, even ExecSQLEx does the same.
Code: Select all
procedure TForm244.Button1Click(Sender: TObject);
begin
ORASession1.Open;
ORASession1.AutoCommit : = True; // This is the default behavior, but I set it again. Does not matter :(
ORASession1.ExecSQLEx('update mydebug set c_ertek1= :x',['x','X']);
end;The only solution is, (luckyli the ExecProcex is virtual), to encapsulate the inherited method call with commit rollback statements.