>
> I wasn't using the services API, I'm not sure what it is. I was
> running gbak with calls to CreateProcess, and identifying the gbak
> executable.

Well this is your problem.

With Superserver, you have a process called fbserver.exe. This process
accepts connections from a client program and fbserver.exe reads and
writes to the fdb file on behalf of those client programs.

Your program is a client application. It talks to the client library
(fbclient.dll), and the client library communicates with the
fbserver.exe process via one of several protocols (eg TCP/IP).

GBak, like your program, is just another client. It connects to the
client library, just like your application, and just like your
application, the client library communicates with the database engine.

The embedded* engine is a deployment model which recognises that not
everyone needs a client-server style model. Firstly, the superserver
engine is merged into the client library. You will notice that the
embedded version of fbclient.dll is significantly larger than the
normal version. That is because it also has the database engine built
into it.

When *your* program loads the embedded client library, the database
engine is loaded into *your* process. When gbak loads the embedded
client library, the database engine is loaded into the gbak process.

This is why you can not run gbak when your database is open by your
embedded application; you have two server instances requiring
exclusive locks on a single file.

Firebird contains something called the Services API; a set of API
functions in the client library that allow you to instruct the engine
to perform certain tasks. For example, your client application can ask
the client library to take a backup, and the client library will then
instruct the server, and the server will do so. How that is exposed
depends on your programming environment and possibly the connectivity
components you are relying upon.

Adam



---
*Embedded - referring to Windows version, it means something entirely
different on Linux.