At 09:12 AM 19/05/2012, bwc3068 wrote:
>it's the latest FB, 32bit, installed 100% with all the defaults (so, not sure >super / classic... it's just the default install) Superserver, then. >i installed into C:\Firebird > >i'm running CMD in C:\Firebird > >I have C:\Temp and in there all there is is vk5.fbk > >it's not NT 4, Fat32, nothing like that. > >gbak -c c:\temp\vk5.fbk c:\temp\vk5.gdb -user nnn -pass mmmm > >that then "worked" or started too... > >of the 7.3 gigs, the VK5.gdb file becase 291 Megs then, it went into a >continous loop with this error: > >gbak: do not recognize table attribute 0 -- continuing > >now... i'm just assuming the FBK file is corrupt or something? Yes. With that small amount of progress through the restore, it's more than likely it hasn't gotten any further than restoring metadata and it is starting to barf on table attributes not supported by Firebird. A possibility is that the database had one or more external tables, that were not converted to internal ones by the backup (-convert switch). A restore would therefore be searching for them on the file path stored in RDB$RELATIONS.RDB$EXTERNAL_FILE. The ExternalFileAccess parameter is NONE by default, which would prevent the use of those external table definitions by the restore. An external table could have been defined with a relative path, too. The "or something" part could be content in the backup that Firebird doesn't recognise. Is it possible that a Firebird version of gbak was used to back up an InterBase database, with no logging to indicate that the backup threw any errors? Or that it was a backup of an IB database made by InterBase's gbak? Can you get a fresh backup, use -verify and send the output to a log file, and make sure that it completes. ./heLen
