Submitted by: mbabuskov (mbabuskov)

Votes: 1

Tried with 1.5.4.4910 and 2.1.0.16780

The problem is that FB tracks stored procedure column dependencies,
but doesn't enforce them when ALTER PROCEDURE is run. You can easily
rename or delete parameters and thus create a database structure that
doesn't survive the backup/restore cycle. Here's a small test case:

Database: test.fdb, User: sysdba
SQL> set term !! ;
SQL> create procedure p1 returns ( x1 integer ) as begin
CON> x1 = 10; suspend;
CON> end !!
SQL> create procedure p2 returns ( x1 integer ) as begin
CON> for select x1 from p1 into :x1 do suspend;
CON> end!!
SQL> alter procedure p1 returns ( x2 integer ) as begin
CON> x2 = 10; suspend;
CON> end!!
SQL> exit!!

Now, backup that database, and when you try to restore it, you would get:

gbak:creating indexes
gbak: committing metadata
gbak: ERROR:invalid request BLR at offset 47
gbak: ERROR: column X1 is not defined in table X1

The error message is also wrong, as X1 is not a table, and procedure name is P1.

As I understand, the parameters are recreated at ALTER statement. To fix the problem, Firebird should not allow the ALTER PROCEDURE statements if there are records in RDB$DEPENDENCIES that reference a parameter that is not going to exists after the statement. This would allow to spot the problem at development time and not much later when user tries to restore the backup (can be too late at that point).

Commits: de7edf7