We do not have ANY stored procedures, triggers, checks, etc. We are not
smart enough to use them and they seemed risky because we would not be
able to see them when we modified/upgraded our software. We simply
read/write/add/subtract records from the databases.
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?
Jack
On 6/11/2015 4:50 PM, Alexey Kovyazin [email protected] [firebird-support]
wrote:
Hello Jack,
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).
Regards,
Alexey Kovyazin
IBSurgeon
--
"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
