Thank you very much. I will try the -o switch and the gfix suggestion
as well.
Jack
On 6/12/2015 2:08 PM, Ann Harrison [email protected]
[firebird-support] wrote:
On 6/11/2015 11:05 AM, Jack Mason [email protected]
[firebird-support] wrote:
However, that won't help us. Our concern is that we have been
backing up our databases for years and it has been a fruitless
exercise. We cannot restore them. We did not have that problem with
Interbase 6 but switched to Firebird because it was touted as being
"modern, safer" etc. Now we find it is virtually worthless unless we
can restore a database it has backed up.
OK. First, there's a -o switch that you should use on the restore if
the normal restore gets an error. That
switch tells gbak to commit after creating the metadata and after
loading data for each table. That will
get you through most problems in backup files. In this case, it will
get you all of your data, indexes, and
constraints.
Second, the problem is somewhere in the privileges you've defined ...
I can't tell which from the
error message.
Third, IBSurgeon has tools that will allow you to fix most broken gbak
backups.
Fourth, in the future, restore one out of ten backups to be sure that
the backup procedure is actually working. That's a good precaution on
any kind of backup. Once in ancient history, we realized after a
crash that we'd been backing up to /dev/null - great optimization, not
so good for recovery.
Nbak has its strengths and weaknesses as well.
Good luck,
Ann
--
"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
