HI, Helen

Thanks for the quick answer. Does it make sense to not include the
metadata if its not involved? In my case, all these stored procedures never
use POSTED this field. I'm not so sure why/how Firebird would be doing
that. Its causing nightmares to maintain my clients' databases every time
when there is a new release which would be sometimes involving updating
their databases by running scripts. There would be having hundreds ALTER
PROCEDUREs in the script because of that one change. Its going to be fun if
we just miss one of these stored procedures in the scripts.

Regards,

William

On Sat, Oct 15, 2011 at 6:53 PM, Helen Borrie <helebor@...> wrote:

> **
>
>
> At 11:13 AM 16/10/2011, william_yuwei wrote:
> >HI, All
> >
> >Using Firebird 2.1.3, I have a table, called, Order, which have a not null
> field POSTED with default source 'N'. Later, I removed this field, but all
> my stored procedures that having UPDATE ORDER SET ...., need to be recomple
> again, even though there is NO POSTED field involved in the UPDATE
> statements. If I won't re-compile these stored procedures, I will get '....
> column 'unknown', values *** null*** ....' error.
>
> The "compiled" BLR, which includes the metadata of objects involved, is
> stored persistently at the time the module is [re]created. It even survives
> backup and restore. It does not magically recompile itself when you alter
> the structure of tables that are operated on by the module. However, I seem
> to recall a bug that allowed you to drop a column or domain that had
> dependencies in BLR. Check the PSQL bug fixes in the v.2.1.4 release notes.
>
> ./hb
>

>
>


[Non-text portions of this message have been removed]