again, thank you for your help. i really do appreciate the support on this group!

it's a very simple DB file. no external tables, nothing fancy. just around 25 tables in the DB and 8 gigs of data. all straight ahead. not even any embedded triggers or user-defined functions or anything. just tables, fields, records.

not a chance it was interbase confused.

i'll just toss the FBK file.

the reason i've pursued it this far (instead of just re-doing the backup) is:

i'm a software developer and was at a customers a long way away. there, i made the backup. and i've been trying to restore it in my office so i could do some work with it.

thanks again.
regards
kelly

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> 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
>