At 03:46 AM 17/03/2005 +0000, you wrote:

>>
>> I'm curious about what you mean by this:
>> > And this is using it on a local machine, not a network install.
>>
>
>Helen: All I meant by that is the database is not on a network. The
>database is on the same machine.
>
>Connection String -> "C:\Program Files\Ipm-
>software\CornerStone\Data\ipms.gdb"

This thread now seems to be in a muddle. You began by reporting the device error and Guardian not able to start the server.

You didn't mention (did you?) whether you disabled SystemRestore on the disk partition[s] where you have databases. If not, this is probably what is getting in the way of gbak: as soon as the program tries to open the backup file, XP launches SystemRestore on the security database...don't know...there's a lot in this thread that's rather fuzzy.

Anyway, let's assume you take the easy route and just change the ".gdb" suffix to ".fdb" and escape the clutches of the Dark Side.

Assuming you can start the server, make it your practice to use the localhost (TCP/IP loopback) server (make sure it's set up in HOSTS first). This way your eliminate the likelihood of corrupting the client/server inter-process communication space by using the local connect.

Then, try to have the service manager run your backup:

gbak -b -se localhost:service_mgr "c:Program Files\Ipm-software\CornerStone\Data\ipms.fdb" c:\backups\ipms.fbk
(quotes needed in the connection path because of the space in the pathname)

Then restore to a path that exists and is visible to the service, NOT using the -r[educe_to_garbage] option:

gbak -c -se localhost:service_mgr c:\backups\ipms.fbk "c:Program Files\Ipm-software\CornerStone\Data\ipms1.fdb"

>> Did you use the official installer to install Firebird, or did you
>just > copy files?
>>
>
>Well, our software installs firebird via a install shield script. We
>have been using it since Firebird 1.0 came out, so I don't really
>think that is the problem.

And it's not worth checking the Registry key?

>I did try something else....We have a few machines in the office set
>up with Firebird 1.5. I can restore this database with version 1.5
>gbak. Strange?

No. That's the standard way to upgrade the ODS of a database. You can't *downgrade* a database, though.

>So I took the newly extracted database and ran a
>backup with version 1.0. When I tried to restore the new backup with
>1.0, it gave the same error "connection lost to database".

This wouldn't be altogether unexpected. Firebird 1.0's gbak (which can restore gbak files made by ODS 10 or lower servers) would not be expected to restore an ODS 10.1 backup file without a fuss. That said, gbak ought to just exit and complain, not crash the server. It could well be SystemRestore locking the security database. This at least needs to be checked and fixed.

>I am not
>sure what to do? I can run the database I extracted using 1.5 on a
>machine with 1.0 installed, but something tells me that is not safe.

The main (probably *only*) ODS difference is that 1.5 creates indexes on some of the system tables. I don't know whether v.1.0 would care about that or not. I'd feel icky trying to operate an ODS 10.1 database under an ODS 10.0 server, though. Let's say -- I would NOT do it, ever. I'd be much more concerned to find out what's wrong with the installation, and fix that - right down to uninstalling it and doing a fresh install using the official installer.

./heLen