If I could set the index inactive, which I can't, the table would
restore with duplicated records. I can just get rid of the duplicates
and restore as well. Doesn't really answer the question of how this
happens.

More research has shown that if I SELECT records using the primary key
I don't get the duplicates as part of the result set. If I SELECT
with PLAN NATURAL I get the duplicates returned. That means that
there are 'orphaned' records in the table that do not belong to the
index. Theoretically this should not be possible since the log file
is showing no corruption.

I wonder if this is a bug that should be reported to the developer list?



After more research
--- In firebird-support@yahoogroups.com, "Alan McDonald" <alan@m...>
wrote:

>
> >
> > On the weekend I tried to backup and restore a database to reorganize
> > it. The restored failed with duplicate keys in a primary key
> > constraint. How is this possible? The primary key constraint should
> > have prevented the creation of duplicate keys in the first place. And
> > before you ask, this constraint has been in place since the database
> > was created. It has never been set inactive because you can't
> > inactivate a primary key constraint. There has never been any hint of
>
> are you sure? I thought there was a problem with 1.0.3 in that you could
> have inactive PK constraints.
> Try to restore setting indexes to inactive and see if it restores.
> Alan
>
> > data corruption either. I'm using Firebird 1.0.3 on W2K.
> >
> >
>