At 10:01 AM 7/05/2009, you wrote:

>Thanks for your answer!
>
>> its says input param mismatch for MyStoredProcedure
>> So it's tleling you that the parameter you declare in MyStoredProcedure
>> doesn't match the expected use inside the proc.

No, it's not telling you that. Stored procedures are not recompiled at restore time: the "compiled" blr is simply copied as-is. The definitions of input parameters, stored in RDB$PROCEDURE_PARAMETERS, *are* restored.

What I think it's telling you is that you have a view, GTT or COMPUTED BY column somewhere, or a CHECK constraint, that is calling this SP with a parameter that doesn't match (for type or size) the corresponding input parameter definition stored in RDB$PROCEDURE_PARAMETERS. Such a mismatch should not have gotten past the compiler (originally), either; so I think you might well suspect someone has been messing about with system tables - perhaps to try to overrule a disallowed change to a domain.

Use the -v[erify] switch on the restore, with -y to send the output to a file. You should be able to discover the last object that was restored successfully. The problem will have been encountered while restoring the *next* object. (Objects of each kind are restored in alphabetical order.)

./heLen