At 11:31 AM 12/09/2007, you wrote:

>Hello Helen,
>
>Thanks for your reply.
>
>Helen wrote:
> > It seems to me you might have problems with conflicting server
> > ports. Could that be the case?
>That would surprise me as conflicting ports should restrict us from
>doing any backup with GBAK.

Here's my theory.

Suppose you have both SS and Classic services running on the same
host machine and you don't have separate ports configured for them to
listen from (both are configured for port 3050). Then you have a
port conflict...but, if SS started first, it will be listening for
connections from port 3050. As soon as one connection is made, the
port is in use. Any external client requests will connect to the
database through this port.

>But the syntax as published in your book
>(without the errata) works just fine on our Classic Server:
>
>gbak -b -se [ServerName]:service_mgr
>[ServerName]:[DBFileName]
>[BackupFileName]
>-user [UserName] -password [Password]

Now, if you run gbak from the bin directory of the Classic server on
the same machine, using the "correct" syntax, it won't work, because
port 3050 is in use and you will get the "Unavailable database"
message. But, if you include the servername in the string, then the
service manager for the Superserver will be found and *it* will
perform the backup via server redirection. Theoretically, that is why
the "correct" syntax can't invoke the service manager on the nearby
Firebird server while the "incorrect" syntax can.

>Nevertheless I have checked our FB Classic Server machine with netstat
>-a -b according to your advice. Here are the results:
>
>TCP FBClassicServerBox:3050 AppServerBox:0 LISTENING 180
>[fb_inet_server.exe]
>
>TCP FBClassicServerBox:3050 AppServerBox:4191 ESTABLISHED 180
>[fb_inet_server.exe]
>
>TCP FBClassicServerBox:3050 AppServerBox:4194 ESTABLISHED 180
>[fb_inet_server.exe]
>
>...
>
>And it goes on like that for many connections established at the time
>netstat ran. Well, they all listen on port 3050 but have different
>incoming port numbers. I can't see a problem here.

The incoming port numbers are irrelevant. What's relevant is whether
you have both servers running on the same box both using the same port numbers.

What version[s] of Firebird is this happening with?

>The [DBFileName] can't be wrong either as my test tool loads it from
>an INI file and it works as long as [ServerName] is specified twice on
>our Classic Server.
>
>I have also compared the versions of FB & its GBAK on
>[FBClassicServerBox] and [AppServerBox]. They are identical.

That's good; but their being mismatched would not account for the
unnatural behaviour of the host service.

>I'd really like to get one syntax to work in both scenarios.

Let's be clear. A remote gbak request must go via the Services
manager. Except for the format of the file paths, which are
platform-dependent, the same (correct) syntax should work regardless
of whether the remote end is SS or Classic and whether it is running
on Windows, HP-UX, Linux, MacOSX or whatever (hence one of the
benefits of using path aliases in Firebird).

But, if you have two Firebird servers (or a Firebird server and an
InterBase server) running on the *same* physical machine, both
listening on port 3050, then there is conflict (competition) for
which service "wins" the port. Only one service can accept
connections to Database X, since Superserver blocks any other service
if it has the database file open; and cannot open the database file
if another service has it open. So that's why I asked if it was
possible that you had both services running on your host machine...

./heLen