Subject Re: Firebird 2.1.1 Gbak Issues
Author Matt Nielsen
I don't use nBackup at all. Have looked at it but haven't implemented anything yet. I am the only person with SYSDBA access. I do make meta data changes during my development process but not during this timeframe.

I don't have any replicators either. I have several applications that use IBObjects components in Delphi and a few .NET clients that use version 1.7 from ibphoenix.org.

Here is the gstat -h dump. I do a backup and restore of the database on a monthly bases to keep things clean and I have never had to use my noon backup but I want it if I need it.

Database "d:\caelix\database\database.db"
Database header page information:
Flags 0
Checksum 12345
Generation 683852
Page size 4096
ODS version 11.1
Oldest transaction 682404
Oldest active 682405
Oldest snapshot 682206
Next transaction 683844
Bumped transaction 1
Sequence number 0
Next attachment ID 50224
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Feb 21, 2009 13:19:01
Attributes

Variable header data:
Sweep interval: 20000
*END*

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 10:53 AM 12/03/2009, you wrote:
> >Sorry about not being very verbose. I should know better.
> >
> >I installed the same server version as the backup like you suggested but the same error as before happened.
> >
> >gbak: ERROR:unsuccessful metadata update
> >gbak: ERROR: TABLE UTMP
> >gbak: ERROR: Can't have relation with only computed fields or constraints
> >gbak:Exiting before completion due to errors
> >
> >Other times when doing the restore when I have tested the noon backup I have gotton other errors and I haven't logged them but I will from now on.
> >
> >I know one other time the error was related to not being able to create an index on a table that did not exist.
> >
> >I'm not sure what the error is referring to since I don't have a table called UTMP. Not sure if that is a system table or not.
>
> Not that I've ever heard of (and I'm *supposed* to have heard of everything!). Persistent system tables all have names starting with 'RDB$' and the monitoring structures (starting with MON$) are not backed up at all.
>
> Do you have someone there who is playing around with your database structure between morning tea and lunchtime? ;-)
>
> Seriously, though, are you running any of the nBackup utilities at all? There *are* some corruption issues there...could you do a gstat -h on the database, look at the Attributes and report them? I simply don't know the internals of nBackup but it's not out of the question that it's able to create temporary structures with uninformative names that are visible to gbak -b under the wrong conditions.
>
> Other possibilities...some other plug-in application (such as a replicator) that is able to modify metadata without exclusive access...or something non-legit that has acquired that capability.
>
> ./heLen
>