Subject | SQLDA Bug Questions |
---|---|
Author | Ben Daniel |
Post date | 2004-01-05T03:07:51Z |
Hi everyone,
We've noticed two errors when using the TIBOStoredProc component with Interbase 5.6
- sometimes we will get a sqlda error when running a stored procedure more than once without doing an unprepare & prepare.
- when we do an unprepare and prepare before calling execproc of TIBOStoredProc as a workaround for the above error, the stored proc will only ever use the param values that were passed to it the first time execproc was called
We believe we've managed to get around both these errors now by creating a TIBOStoredProc descendant and using it in place of TIBOStoredProc. Basically we just overrode the ExecProc method and made a copy of the param values, unprepared the stored proc, prepared it again and then copied the param values back in again before doing the inherited ExecProc.
type
TPCSIBOStoredProc = class(TIBOStoredProc)
public
procedure ExecProc; reintroduce; virtual;
end;
implementation
procedure TPCSIBOStoredProc.ExecProc;
var AParams: TParams;
begin
AParams := TParams.Create(nil);
try
AParams.Assign(Self.Params);
Unprepare;
Prepare;
Self.Params.AssignValues(AParams);
finally
FreeAndNil(AParams);
end;
inherited;
end;
Since we have no option but to stay with Interbase 5.6 for the time being and we'd like to continue to use ibo rather than having to go back to the bde we'd like to know the following:
- are there any other places the sqlda error surfaces in ibo? is it just in stored procedures?
- is it possible we might get the sqlda error when referring to a stored procedure in a query (e.g. 'Execute Procedure MyProc' or 'Select * From MyProc')
- can you get an sqlda error when just doing a select from a table/view?
- is there anything we need to worry about in our wrapper component as a consequence of calling unprepare & prepare before execproc other than reassigning the params?
- how does the bde avoid the sqlda error? if it uses a workaround, does anybody know how it works around it?
Thanks for you help,
Ben
[Non-text portions of this message have been removed]
We've noticed two errors when using the TIBOStoredProc component with Interbase 5.6
- sometimes we will get a sqlda error when running a stored procedure more than once without doing an unprepare & prepare.
- when we do an unprepare and prepare before calling execproc of TIBOStoredProc as a workaround for the above error, the stored proc will only ever use the param values that were passed to it the first time execproc was called
We believe we've managed to get around both these errors now by creating a TIBOStoredProc descendant and using it in place of TIBOStoredProc. Basically we just overrode the ExecProc method and made a copy of the param values, unprepared the stored proc, prepared it again and then copied the param values back in again before doing the inherited ExecProc.
type
TPCSIBOStoredProc = class(TIBOStoredProc)
public
procedure ExecProc; reintroduce; virtual;
end;
implementation
procedure TPCSIBOStoredProc.ExecProc;
var AParams: TParams;
begin
AParams := TParams.Create(nil);
try
AParams.Assign(Self.Params);
Unprepare;
Prepare;
Self.Params.AssignValues(AParams);
finally
FreeAndNil(AParams);
end;
inherited;
end;
Since we have no option but to stay with Interbase 5.6 for the time being and we'd like to continue to use ibo rather than having to go back to the bde we'd like to know the following:
- are there any other places the sqlda error surfaces in ibo? is it just in stored procedures?
- is it possible we might get the sqlda error when referring to a stored procedure in a query (e.g. 'Execute Procedure MyProc' or 'Select * From MyProc')
- can you get an sqlda error when just doing a select from a table/view?
- is there anything we need to worry about in our wrapper component as a consequence of calling unprepare & prepare before execproc other than reassigning the params?
- how does the bde avoid the sqlda error? if it uses a workaround, does anybody know how it works around it?
Thanks for you help,
Ben
[Non-text portions of this message have been removed]