--- In firebird-support@yahoogroups.com, Bradley Tate <btate@o...>
wrote:

> Hi all,
>
> For the second time the backup of our 3G Firebird 1.0.3 database has
> been corrupted. We do a backup and restore nightly for QA and for

use

> in other systems. All tables in the restored database then appear

empty

> i.e. result sets from selects are empty and the roles have

disappeared.

> We suspected a permission problem but even when we add permissions

back

> using grant all we still cannot get access to any data from any

table

> even logging in as sysdba. There are no errors reported from the

backup

> or restore process, and gfix reports nothing wrong with either the
> restored database or the original.

Looks strange. I haven'nt failed restore since FB1 RC2 so can't
assure you that FB1.0.3 g-utilities always return error message, but
it's really doubtful.

> To try and track down the problem we did the restore in Firebird 1.5

RC8

> and it tells us that one of our tables has a duplicate on the

primary

> key. The problem is if we go back to our original database and do a
> select it performs as expected and there is no evidence of this.

What kind of select did you do? Something like

Select Count(*), ID
From This_Table
Group By ID
Having Count(*)>1 ?

Don't forget to add Plan (This_Table Natural) to such a query. Most
probably engine used index and this index have no link to duplicated
row. Check this table for NULLs in PK too, again forcing natural scan.

> Given
> that we know what the problem is we can fix it (copy table, drop
> original, copy back) but does anybody have any idea what could be
> causing it so we can stop it happening again? We're suspicious that

the

> backup is getting too much data i.e. records which should not exist

any

> more.
> The original database is running on Linux (RedHat 7.3)

Don't think so. 3Gb is'nt very large database, my own is about 8 and
run on Red Hat too, survived many versions of both RH and FB. In my
practice such a corruptions were sometimes caused by killing processes
of Classic server. I think crash of Super can make the same damage.
Another reason I know is file access to database in use, third -
hidden hardware defects, usually RAM or disk controller. BTW, in FB1.5
were fixed several ancient bugs around savepoints and mass
inserts/updates which seldom could lead to such a corruptions.

Best regards,
Alexander.