At 07:27 PM 15/11/2007, you wrote:

>hi helen,
>1) server directory means: a directory on the server machine where
>firebird is installed.

Ah, that explains your problems then.

>2) command submited via cmd-command from uor application:
>\\servername\...\prog\gbak.exe -b -user SYSDBA -pas xxx -V -y
>C:/DOCUME~1/falko/LOCALS~1/Temp/gbakerr.txt
>"BAUSUDB:E:/DBPUBLIC/_FM/SCH_AUFM.GDB"
>"//BAUSUDB/DBPUBLIC/_FM/SCH_AUFM.GBK"

Nope. I have no idea what "cmd-command from uor application" means but the way you are doing this looks to be tangled up with mixes of Windows network mapped accesses.

In short, to run gbak from a *remote client*, you must use access the Services Manager at the server. There is a specific command-line syntax for it. (where hostname refers to the actual hardware node name of the machine that is hosting the server, not anything else):

..\client-local\path\to\gbak -b -se service_mgr:hostname E:\DBPUBLIC\_FM/SCH_AUFM.GDB \\canbe\network\path\_FM/SCH_AUFM.GBK -user SYSDBA -pas xxx -V -y
\\canbe\network\path\gbakerr.txt

(all of the above in a single command)

Explaining the path-holder "\\canbe\network\path\", if you want the server to deliver the backup file and/or the verbose output file to a location on your client machine, it has to be via a network path by which the remote host machine can access your machine.

>3) in \prog directory there is fbclient.dll and firebird.msg
>
>4) no accessing through network mapping

But there was: you were trying to invoke the gbak executable through a network mapping.

To be clear: the gbak.exe PROGRAM can be run remotely but you have to use the Services Manager. In that case the program connects to the remote server and asks it to execute the backup from within the server's Services subsystem. Like any remote client, it accepts and interprets error messages that are delivered *from the server*. So you don't need a local copy of firebird.msg at the remote client.

>what i found out:
>a) everything works fine when i do the gbak from a client which has FB
>installed
>b) if i rename the firebird registry-key on that client the
>gbak-error-log is full of mesages mentioned above ?!?!?!
>
>so my conclusion is:
>gbak looks for the firebird registry key to get the location of the
>firebird.msg!!!

As a last resort, when it thinks it is being asked to perform a local backup, it will look there. But gbak, when run as remote application, does not need firebird.msg and does not (and does not need to) search the Registry.

>==> every client must have firebird installed to locate the
>firebird.msg even if all databases are located on the database-server
>machine!?!?
>-> but that is not what i think of a client/server application

No...you need to do a bit more research on some of these things, it seems, and maybe get a better understanding of the difference between "client/server" and "filesystem-served". On a client/server system you will hit barriers when you try to fool the system into thinking it is filesystem-served.

>is there another solution to this which has no need of any firebird
>stuff installed on the client?

Yep, just do it properly. :-)

>by the way: because of all the trouble with gbak i thought about using
>the firebird services api for backup/restore.
>what are the disadvantages of using services api instead of gbak.exe?

No difference. The Services API is just a front-end to the same code that the Services manager executes when gbak invokes it remotely.

>what delphi-components do you recommend? iboadmin-components?

I use them, but really just because IBO is my programming environment. Any reputable Delphi implementations of the Services API should do the trick. If you're a member of the ibobjects yahoo group, you can download some demos from the list's Files area.

./heLen