|Subject||Re: [firebird-support] Firebird 2.52 gbak fails to do a restore - error trigger (3)|
We were told that backing up with Interbase gbak and restoring with Firebird gbak was the proper migration procedure, but that is apparently not true?
Why is everyone else not having this problem? The databases are Firebird databases. For 15 years we had no corruption from Interbase 6. Two years ago, we backed up our databases with Interbase 6 gbak and then used Firebird 2.52 to restore them.
It can be an answer - when you perform backup/restore, complied codes of stored procedures, triggers, checks, etc are not upgraded to the new BLR version, so you still have old BLR (in IB6 format) inside. However, any change in source code will lead re-complication of the database object, and it can fail (for number of reasons, like ambiguous fields references) - and at restore step this will be revealed and various problems can occur.
Firebird 2.52 will back them up, but will not restore them without getting the "trigger (3)" error. Since we have 5 databases, each built by Firebird two years ago from Interbase 6 backups and backed up for two years by Firebird 2.52 gbak, and totally different programs accessing the databases, it appears the corruption is/has been caused by Firebird.
Well, your problem does not look like something very simple. I think you should think about proper migration procedure (to make database 100% compatible with Firebird 2.5).
"Our Constitution was made only for a moral and religious people. It is wholly inadequate to the government of any other." -- John Adams, Oct. 11, 1798 "Where there is no vision, the people perish.." Prov 29:18