| Subject | Re: [firebird-support] Re: Firebird 2.1.1 Gbak Issues |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-03-12T00:25:24Z |
At 10:53 AM 12/03/2009, you wrote:
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
>Sorry about not being very verbose. I should know better.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.
>
>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.
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