Subject | Re: [firebird-support] How can I see if there are invalid objects in my db? |
---|---|
Author | Helen Borrie |
Post date | 2005-02-04T21:56:11Z |
At 05:01 PM 4/02/2005 +0100, you wrote:
will cause exceptions when you try to perform unsafe metadata changes.
The one thing that you do have to watch out for is when you alter a stored
procedure that is called by another stored procedure or by a trigger. Make
sure you to run a RECREATE PROCEDURE or CREATE OR ALTER TRIGGER on the
calling procedure, after committing the called procedure, in order to
recompile the calling procedure. You should make it a golden rule not to
mess about with compiled objects without first doing a database shutdown,
too. Failing to do so won't corrupt data but it is likely to give rise to
metadata consistency checks that show up as unhandled exceptions for users.
What *will* cause dependency problems is trying to alter metadata by
updating the system tables directly. Never do this, and don't use tools
that do it under the hood.
./heLen
>Hi,You won't get "invalid objects", per se, in Firebird, since dependencies
>
> Can any one tell me, how can I see if a view, trigger or stored
>procedure has become invalid, that is to say, when it must be recompiled
>o recreated.
>
> Is there any field in database catalog (RDB$ tables) which tells me
>this? Any script or tool which can help with this. Even more, how can I
>make this automatically after modifying database objects.
>
> We are working with Firebird 1.0.3 and Delphi 6 and sometimes our
>application doesn't work till we recompile a certain stored procedure.
will cause exceptions when you try to perform unsafe metadata changes.
The one thing that you do have to watch out for is when you alter a stored
procedure that is called by another stored procedure or by a trigger. Make
sure you to run a RECREATE PROCEDURE or CREATE OR ALTER TRIGGER on the
calling procedure, after committing the called procedure, in order to
recompile the calling procedure. You should make it a golden rule not to
mess about with compiled objects without first doing a database shutdown,
too. Failing to do so won't corrupt data but it is likely to give rise to
metadata consistency checks that show up as unhandled exceptions for users.
What *will* cause dependency problems is trying to alter metadata by
updating the system tables directly. Never do this, and don't use tools
that do it under the hood.
./heLen