Helen,

This is the exact message from firebird and I have attached an extract
of text before it failed.

/Attempt to store duplicate value (visible to active transactions) in
unique index "RDB$PRIMARY388"/

Service started at 19/02/2004 5:14:33 PM
gbak: opened file /databases/interbase/work/bmc/transact_current.gbk
gbak: transportable backup -- data in XDR format
gbak: backup file is compressed
gbak: created database /databases/interbase/work/bmc/transact_current.gdb, page_size 4096 bytes
gbak: started transaction
gbak: restoring domain RDB$1
gbak: restoring domain RDB$2
gbak: restoring domain RDB$3
gbak: restoring domain RDB$4
gbak: restoring domain RDB$5
gbak: restoring domain RDB$6
gbak: restoring domain RDB$6931
gbak: restoring domain RDB$6932
gbak: restoring domain RDB$6933
gbak: restoring domain RDB$6934
gbak: restoring domain RDB$44907
gbak: restoring domain RDB$44908

<snip lots of other text>

gbak: restoring index OPENANNUITY_INVHEADREF
gbak: restoring index RDB$PRIMARY237
gbak: restoring index RDB$PRIMARY697
gbak: restoring index COMMPAID_LEDGERREF
gbak: restoring index RDB$PRIMARY291
gbak: restoring index ITBATCHLINK_ITBATCHREF
gbak: restoring index ITBATCHLINK_INVTRANREF
gbak: restoring index RDB$PRIMARY638
gbak: restoring index RDB$PRIMARY304
gbak: restoring index REGINFO_INVHEADREF
gbak: restoring index REGINFO_TRANTYPE
gbak: restoring index REGINFO_AMOUNTTYPE
gbak: restoring index REGINFO_ESCALATION
gbak: restoring index REGINFO_FREQPERIOD
gbak: restoring index REGINFO_PROTTYPE
gbak: restoring index RDB$PRIMARY302

Doesn't look like system tables to me.

Cheers and thanks,

Bradley.


Helen Borrie wrote:

> 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
>
>
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
>
> * To visit your group on the web, go to:
> http://groups.yahoo.com/group/firebird-support/
>
> * To unsubscribe from this group, send an email to:
> firebird-support-unsubscribe@yahoogroups.com
> <mailto:firebird-support-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service <http://docs.yahoo.com/info/terms/>.
>
>