Thank you for your response.

> Looking back at your old postings on this issue, I smell
> an elephant in the room. Have you been developing these
> apps with the renamed fbembed.dll as the client that is
> loaded by the IDE? You should not do that. Embedded is
> a deployment option ONLY - it does not belong in your
> development environment.

I've never heard this--but it seems to be peripheral to the core problem.

I use FBClient.DLL for deployment. Installing FB 1.5. It has worked for years both in deployment and in development.

I believe in developing as close as I can with the same way my users are going to use it, which you say isn't right?

> Develop and compile with Superserver and the regular client,
> using cpLocal as the connection protocol. Set up your test
> installation for embedded totally external to the project
> structure and copy the executable over to it each time you
> compile. If you are running the test installation on the
> same box as a running fbserver then, until you are certain
> that the detached executable is finding the fbembed library
> correctly, shut down Superserver while testing it as an
> embedded app.

But not in the IDE? Why?

> Also, use gfix to set Forced Writes ON. Don't rely on it to be
> set by the client app if you ever intend upgrading Firebird.
> Beyond Fb 2.0.6 and 2.1.2, ordinary users can't change database
> header settings via the API. But, even if you're going to stick
> with v.1.5.6 for ever, it's still not a thing you should be
> enabling for ordinary users. Check and double-check the Params of
> your connection object and get rid of everything that can modify
> the database header.

I'm not sure which params would modify the DB header. How would I know?

Ed Dressel