Hi Jörg,

I have been through the demo that you sent, I can reproduce the
problem in Delphi5 very simply once I knew where to look.

In fact I can ignore the StoredProcHasSelect and StoredProcHasDML
properties altogether. Just assigning the "SELECT * FROM PROC( ..."
to the SQL of TIB_StoredProc is sufficient to generator the error.

I am really not sure of the best fix for the problem in TIB_StoredProc
(in fact I suspect that there are two bugs revealed by the demo that
you sent). Is there any reason why you cannot use TIB_Cursor to
implement what you want? In my experience it works very well for
select stored procs and is really (IMHO) the best match for anything
returned via "select".


The following is mostly for Jason's benefit:

When the stored proc SQL property is changed it calls
TIB_StoredProc.SysSQLChange, that function calls SysKeyRelation which
does this...

CheckConnection( false );
if Assigned( IB_Connection ) then
Result := IB_Connection.mkIdent( Result );

mkIdent needs the connection to be active in order to know how the
relation name (Result) should be formatted. And this is where the
exception occurs.

So we need the SysSQLChange to be able to operate without a valid
connection. That in itself is easy enough, but I am uncertain about
what may be required to ensure that the initialisation attempted in
OnSQLChange is done when the connection does become available - or
what impact may be had by the fact that the assignment causing the
problem:
FStoredProcName := SysKeyRelation;
may be inaccurate while the connection is not active.

The second "bug" that seems to appear in this instance is that at the
bottom of TIB_Dataset.SysKeyRelation where this code...
if Assigned( IB_Connection ) then
Result := IB_Connection.mkIdent( Result );
appears, the Result includes the openning bracket of the procedure
name.


Geoff Worboys
Telesis Computing