Hi,

At September 9, 2003, 12:42, Henryk Paluch wrote:

> Agreed. I was confused by another problem (at least on SuperServer
> 1.0.x) - when B changes then A still calls old version of B (some
> extensive caching of A?).

No, the problem with FB 1.0 is that it was recompiling the procedure
before dropping it. Essentially, when DROP PROCEDURE A was executed,
the server tried to recompile A before deleting it. This behavior is
the cause to Peppe's problem, and it is fixed in FB 1.5.

> Recompilation of A or restart of database will
> help.

No, it will not help. Because you have to manually make the changes to
A to reflect the changes made to the parameters of B. The only time
that changes in the output parameters of one SP that will not affect a
dependent SP/Trigger is when it is a selectable SP and specifying each
return field in the SELECT statement. But, if you use the EXECUTE
PROCEDURE statement, then all the parameters have to be defined in the
statement and they have to match with the parameters of the SP that is
being called.

--
Best regards,
Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)