At 10:42 PM 3/09/2003 +0000, you wrote:

>--- In firebird-support@yahoogroups.com, Milan Babuskov <albis@e...>
>wrote:
>
> > Unless you tell us what exaclty did you do
>
>step 1:
>
>create procedure test
>returns
>(result integer)
>as
>begin
> result=1;
> suspend;
>end
>
>step 2:
>
>create procedure test1
>returns
>(result integer)
>as
>begin
> select result from test into :result;
> suspend;
>end
>
>step 3:
>
>(try procedure test1)
>
>select result from test1
>
>Result=1 (as expected)
>
>step 4:
>
>alter procedure test
>returns
>(result integer)
>as
>begin
> result=2;
> suspend;
>end
>
>step 5:
>
>(try procedure test1)
>
>select result from test1
>
>Result=1 (instead of the expected value 2)
>
>Isn't this a bug ?

No, it's intended behaviour. SPs are triggers are compiled objects.
Changes to them are deferred until any existing transactions linked to it
are committed. So try committing the original query and then run your
altered SP again. (Note that, if you are using a tool that performs
CommitRetaining, the old version of the SP is still "engaged".)

heLen