On Wed, Feb 16, 2011 at 2:12 PM, Helen Borrie <helebor@...> wrote:

>
>
> First of all, please do not cross-post.
>
Ok. I crossposted because the issue involves both sides, .NET & Firebird
embedded. My apologies.

>My strategy was to put purposely bad values in the
> >file to see that Firebird chokes on them -- at this point, I'm
> >wondering if Firebird just skips unknown settings
>
> Yes. Each engine version reads only the parameters it knows about.
>
That explains one thing. The bogus setting "adsfasdf" I put in the file
would be ignored, then.


> > 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 uncommented the following setting & set its value to a non-integer:
DefaultDbCachePages = test bad value!!! #16384

Either firebird ignored it or the firebird.conf wasn't found because the
database happily started up & ran.

>I've tried placing firebird.conf in all of the following locations,
> >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
>
> 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.
>
> While I agree with you for traditional native applications, this actually
changes for .NET (and Java, I imagine). My .NET app is bitness-agnostic.
The same .NET assemblies can run unmodified on 32- and 64-bit platforms.
Because of that, I include two subdirectories when I deploy the .NET
application. I call one "Bin32", and the other "Bin64". Bin32 contains the
32-bit Firebird DLLs, Bin64 contains the 64-bit ones. Then, at runtime, in
.NET, I detect the bitness of the process using a standard .NET method, and
then use the Windows API SetDllDirectory via P/Invoke to dynamically add
Bin32 or Bin64 to the executable's path. Everything works fine, and the
properly bitted DLLs get loaded. That's how the application directory where
my executable is located is different from the location where fbembed.dll &
its dependencies are. Again, I've tried placing firebird.conf next to my
.exe, next to fbembed.dll (in Bin32 or Bin64), and next to the database file
with no errors, despite my bad integer value.


> 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.
>
Yes, the database file is located outside of my application's directory tree
-- somewhere else completely, and configured via the .NET provider's
connection string, not in firebird.conf.


>
> >I've also searched quite a bit to figure out how I might crank up the
> >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?
>
> "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.
>
> 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.
>
> I actually use the embedded version just fine in my integration tests that
are run from directly within Visual Studio. No need for superserver &
xnet. I can also launch & debug my app from within VS without a problem. I
think it works, to a large degree, because I'm making sure that Bin32 or
Bin64 is on the path, and the .NET provider's connection string let's me
specify the full pathname to the database file.


> 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.
>
I also do that. Once compilation is complete, I basically have the
following structure, relative to the directory containing my Visual Studio
project file (shown as $ below):
$\
bin\
Debug\
my .exe & the .NET assemblies it depends on, including
FirebirdSql.Data.FirebirdClient.dll
Bin32\
32-bit Firebird DLLs & firebird.msg
Bin64\
64-bit Firebird DLLs & firebird.msg

On app launch, I dynamically add $\bin\Debug\Bin32 or $\bin\Debug\Bin64 to
the path & we're off & running.

Make sense? Again, thanks for your help, and let me know what you think.
I'll try to have a look at the firebird source to see how it attempts to
locate firebird.conf. It seems to me that I should be able to either set
everything that's in firebird.conf via the .NET provider's connection
string, or the .NET provider connection string should provide me with a
setting to tell it where to find (absolute or relative pathname) the
configuration file, which I'd prefer to not have to be named
"firebird.conf".

Thanks,
Matthew


[Non-text portions of this message have been removed]