Hello Helen,

Thanks for your reply.

Helen wrote:

> You don't need to bother - it is not a bug, it is "as
> designed". Classic on Windows cannot take a client connection via
> the legacy IPServer that is in Firebird prior to V.2. So you should
> always take the sensible route and use localhost (for local
> connections) or the proper hostname (for remote connections) if you
> are letting users use the command-line tools, regardless of whether
> you expect them to connect to Classic or Superserver.

It is actually the application server that needs to know how to backup
& restore. First I used TIBBackupService (as I am running Super Server
on my development machines). But as you have written quite a while ago
that doesn't play well with the Classic Server of Firebird. So I
swapped to calling gbak with ShellExecuteEx inside the application
server. I was hoping to be able to use one way of constructing my
parameters for gbak inside the application server. And it should
really work the way you describe it.

Unfortunately this is not in my development environment. In order to
proof it to myself I used two Virtual PCs running Windows XP and
nothing else. I installed FB Classic Server on VirtualPC2 and the
command line tools on VirtualPC1. That way I could call

gbak -b -se VirtualPC2:service_mgr
VirtualPC2:C:\Employee.fdb
C:\Employee.fbk
-user sysdba -password masterkey

or even

gbak -b -se VirtualPC2:service_mgr
localhost:C:\Employee.fdb
C:\Employee.fbk
-user sysdba -password masterkey

for that matter. But as soon as it is FB Super Server 1.5.4 running on
VirtualPC2 the only way it works is

gbak -b -se VirtualPC2:service_mgr
C:\Employee.fdb
C:\Employee.fbk
-user sysdba -password masterkey

as per your errata HTML file.

I have come to the conclusion that I will store whether it is a
Classic or Super server in the INI file of the application server and
build the parameter list for gbak accordingly before calling
ShellExecuteEx.

Thanks for all your help, Helen.

Salut,
Mathias