At 06:43 AM 17/11/2011, Ed Dressel wrote:

>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.

So embedded is not in the picture then. I must have misinterpreted your original post on this thread.

>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?

It isn't right if you are developing an app for use with embedded Firebird prior to v.2.5.

> > 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?

Because embedded prior to v.2.5 embeds a Superserver engine. SS deliberately allows only one instance of itself to connect to a database in read/write. So if the IDE has a connection already, it has the write lock and it is denied to the application.

But it seems not to be the issue, if you are actually developing and deploying with the full server.

>> 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?

The quickest way would be for you to read the Fb 2.0.6 or Fb 2.1.4 release notes, where the issue is explained in the API and ODS chapter. Both are available in HTML at the Firebird website (Documentation pages). It should be easy enough to match up the names of those API dpb members with both the Connection properties and the array members in Connection.Params.

Helen