At 01:37 PM 23/07/2009, you wrote:

>Hi,
>
>> but this is what is happening:
>> C:\Program Files (x86)\Firebird\bin>gbak -c -v -user SYSDBA -password
>> masterkey c:\temp\retdata.bak
>> c:\temp\test.fdb
>> gbak: opened file c:\temp\retdata.bak
>> gbak: cannot open backup file C:\temp\test.fdb
>> gbak: Exiting before completion due to errors
>
>try using TCP:
>
>gbak -c -v -user SYSDBA -password masterkey c:\temp\retdata.bak
>localhost:c:\temp\test.fdb

The above syntax won't work in 2.1.

gbak -c -se localhost:service_mgr -user SYSDBA -password masterkey c:\temp\retdata.bak c:\temp\test.fdb -page_size 4096 -v -y c:\temp\test_rst.log

If you get any errors about parameters (invalid, etc.) then try moving the -user and -password switches to just before the -v switch.

The error message is a pain though. It's the "right" error message in a sense (either it created the file in its CREATE DATABASE procedure but can't open it for some reason, possibly permissions OR it can't open the file for a restore because it already exists, which gbak -c is not allowed to do) but it's attributing the error to the wrong argument in the command.

Try to see if you can reproduce that reliably. If so, it's a regression bug in 2.1.2 that *might* just get fixed for the 2.1.3 release if QA can be alerted to it.

The likely cause is that one of your previous attempts actually did create the file, even though the restore failed. Always check that and either delete the file after the failed attempt, or use a different name for the next attempt.

./heLen