Scott Marcellus wrote: > I have been trying to use different restores for the > past couple of weeks for one specific database and it seems I am > able to restore the database with data in the database restores > tables but it does not have any procedures or views or anything like > that. I am able to restore other databases fine and I am using the > same command for all. The screen output and execution for the > troublesome database appears to just stop. Is anyone able to give me insight > into this issue?
> Here is the command I am using: > gbak -create -recreate -replace -verify -user XXX -password YYYY > "c:\somepath\somefile.bak" Server:c:\somepath\somefile.fdb First of all, the -create, -recreate_database and -replace_database switches are mutually exclusive. However, if that worked for some of the restores, it is likely gbak is just ignoring the others. Still, decide which one you need and use it alone. Note that you will need the OVERWRITE argument with the replace_database switch if the database exists already in the specified location. The -create switch won't work at all if that database is already there. > Here is the restore log for the problematic db restore: > gbak: activating and creating deferred index FK_xxxxxxxxx > gbak: activating and creating deferred index FK_yyyyyyyyy > gbak: activating and creating deferred index FK_zzzzzzzzz > gbak:committing metadata Secondly, you need to look in the firebird.log for some clue as to what went wrong during the commit of the metadata. If an out-of-disk condition was encountered, it would be logged there. What you won't see, though, is a situation where another program has locked the file that the database is being restored to - think backup programs, antivirus, Windows VSS. Is there a possibility that you are trying to restore from a backup that didn't complete? Or from a metadata-only backup? Do you have access to the database so that you can make a fresh backup in the original server environment and monitor it yourself? Another factor could be that the backup was from a database with on-disk structure (ODS) 11.0 or older being restored to ODS 11.1 or higher. You may need to include the -fix_fss_M switch to have text in metadata (such as CHECK constraints) converted to unicode_fss. Helen --- This email has been checked for viruses by AVG. https://www.avg.com
