Lets be more accurate here...

The entrypoint can't be found because the DSQL statement can't be processed
locally, so it must be processed on the server...
Fine, no problem.... but the call for isc_dsql_immed2 drops into the
isc_dsql_exec_immed3_m (Prepare a statement for execution) function in
why.c
When the PROC_DSQL_IMMED2 entrypoint can't be found, it should ideally try
and enter the relevant subsytem for that call, instead it falls through into
dsql8_execute_immediate or rather GDS_DSQL_EXECUTE_IMMED in dsql.c

A normal isc_dsql_execute drops into isc_dsql_execute2_m (execute a
non-SELECT dynamic SQL statement) interesting when the satetment actually is
select last_name from employee where emp_no =2 and then drops directly into
the dsql8_execute subsystem or rather GDS_DSQL_EXECUTE in dsql.c

So there doesn't seem to be anywhere for an exec_immed2 to go.... the bug
referred to previoudly where this call crashed the server, seems to have
been fixed by falling through to GDS_DSQL_EXECUTE_IMMED, the upshot of that,
is that the call no longer crashes the server, but if you want to use it
with an output sqlda it can't ever work.

On Windows all it does is crash the program that tries to make the call
rather than the server itself.

Now I wonder how or what we should map exec_immed2 to in dsql.c so that when
the call gets executed it enters a proper subsystem that can handle it.

Regards
Paul Beach
Main Tel (UK):+44 (0) 1844 354465
Mobile: (UK): +44 (0) 7764 188603
http://www.ibphoenix.com
For all your upto date Firebird and
InterBase information