At 02:05 PM 19/02/2004 +1100, you wrote:

>I'm wondering how I can get a duplicate primary key in the backup (per
>the FB1.5 error message) but there is no indication of it in the
>original database and the 1.0.3 restore process doesn't notice it at
>all. This has me quite worried as our company lives and dies by our
>database.

It could be that the error message doesn't relate to one of your tables at
all, but to a system table (possibly rdb$relation_fields). There were no
keys on the system tables in 1.0.3 but in 1.5 they were added to several,
to speed up searches. Take a lot at your definitions - especially if you
have a view that involves a join - and check that you have all unique
column names there.

On restoring, if gbak 1.5 encountered two records for insertion into e.g.
rdb$relation_fields with the same PK value (rdb$field_name +
rdb$relation_name) then you'll get this exception. A possible source could
be where you have two or more fields in a view that are based on
expressions and you didn't assign explicit fieldnames to them...

If the latter turns out to be the cause, I'd like to know. I consider it a
bug that you're allowed to output nameless fields at all (though Claudio
yells his head off at the *very idea*). If allowing it has the potential
to break metadata then the argument for disallowing it gets an incremental
boost.

/heLen