| Subject | Re: [firebird-support] Search algorithm & startup logging of search for firebird.conf? |
|---|---|
| Author | Helen Borrie |
| Post date | 2011-02-16T20:12:05Z |
First of all, please do not cross-post.
At 08:06 AM 17/02/2011, Matthew Adams wrote:
The database file can be anywhere on the host's physical filesystem...and an app can access multiple dbs in multiple locations in the filesystem if it needs to.
I don't know of anything that's dedicated to the task, other than running the debug version and making sense of its output. Or you could look at the source code if you need to know in detail what happens at startup.
All that said, it does seem that you are struggling with the basic concept. Are you trying to do all this playing about inside VS? The embedded model is for *deployment*, not for development. Perhaps that's why you're coming to grief....?
For development, write your app using Superserver and the standard fbclient.dll that fits the platform as a client, use database aliases (for 10 good reasons!!) and the "serverless local" connection protocol (XNET). That's your *development* setup. When it works there, it will work as an embedded app if you do everything correctly.
Set up your embedded app separately in a self-contained file structure. When you want to test embedded specifically, copy your executable over there. Ask on the net-provider list whether you actually need to compile separate executables...I'm not familiar with the dotNet environment or exactly how the provider implements the API.
./heLen
At 08:06 AM 17/02/2011, Matthew Adams wrote:
>Hi all,Yes, it does, if it is located in the same directory as fbembed.dll.
>
>I'm having some trouble determining whether Firebird 2.5 Embedded on
>Windows 7 used via the Firebird .NET Provider 2.6.0 is reading
>firebird.conf.
>My strategy was to put purposely bad values in theYes. Each engine version reads only the parameters it knows about.
>file to see that Firebird chokes on them -- at this point, I'm
>wondering if Firebird just skips unknown settings
> or settings with bad values.Depends on what kind of values they are. For example, if you put in an invalid string value for a path, it would baulk. For a Boolean, afaik, 0=off/false, anything else=on/true. Integer parameters, depends on what you put there.
>I've tried placing firebird.conf in all of the following locations,There's only one place it is read - in the application directory where your executable is - which is also where fbembed.dll has to be. Look at the v.2.1 release notes and the Migration/Installation doc for details of the structure of an embedded app. Location of fbembed.dll doesn't "differ based on 32/bit" though. Are you trying to deploy a 32-bit app with the 64-bit dll (or vice versa)? Don't. Decide which one it's going to be and make them match.
>and I haven't been able to confirm whether it's being read:
>
>* Current working directory
>* Right next to fbembed.dll (differs based on 32/64 bit)
>* Right next to the database file
The database file can be anywhere on the host's physical filesystem...and an app can access multiple dbs in multiple locations in the filesystem if it needs to.
>I've also searched quite a bit to figure out how I might crank up the"Bootstrapping" isn't in the picture. The application loads the client into its workspace, which happens to include the dedicated server instance. The application asks, via the client, for the server to connect to a database. If all is correct, the embedded server spawns a thread and you're away.
>logging level of Firebird's bootstrapping process without much luck.
>How can I see what Firebird is doing on startup, in particular with
>regard to which firebird.conf, if any, it's looking for?
I don't know of anything that's dedicated to the task, other than running the debug version and making sense of its output. Or you could look at the source code if you need to know in detail what happens at startup.
All that said, it does seem that you are struggling with the basic concept. Are you trying to do all this playing about inside VS? The embedded model is for *deployment*, not for development. Perhaps that's why you're coming to grief....?
For development, write your app using Superserver and the standard fbclient.dll that fits the platform as a client, use database aliases (for 10 good reasons!!) and the "serverless local" connection protocol (XNET). That's your *development* setup. When it works there, it will work as an embedded app if you do everything correctly.
Set up your embedded app separately in a self-contained file structure. When you want to test embedded specifically, copy your executable over there. Ask on the net-provider list whether you actually need to compile separate executables...I'm not familiar with the dotNet environment or exactly how the provider implements the API.
./heLen