Hi Helen

Thanks for your suggestion.

> One possible ploy is to have a "dummy user" for the app when it
> connects: one that is allowed to do stuff according to the

database

> privileges (e.g. define an "all_users" role and assign it to
> user "dummy" as well as other legit user[s]). A full server will
> reject the user if it doesn't exist in the security database - so
> catch this exception and use it to strip out the server element

from

> the connection string before reconnecting. As long as the role
> exists, an embedded server will accept any username.

There is a simple problem (and paradoxically a possible solution)
with this approach.

On Joe Average's XP machine, Firebird is not installed. The whole
reason for using the embedded engine is to avoid having to do this
(requires admin rights to install the service etc), so the only
possible way to connect would be through a local connection. Using a
TCP connection will not succeed.

On a Win2003 server running terminal services, a local connection
will not suceed. This is a known limitation of Firebird/that
environment. The TCP connection would providing a Firebird server was
running.

The possible solution would be to attempt a local connection, and if
that failed to attempt a TCP connection. I just thought there may be
a string somewhere accessible through the api or in the file header
about whether it is embedded or not.

To me more specific. The application is a tier in an n-tier model. I
am migrating what used to be handled by a bunch of csv files at each
tier into a Firebird database for 3 main reasons.

1) I want atomicity.
2) I want writers to not block my readers and vice versa because this
will solve a current bottleneck. With csvs you effectively have a
table lock when editing.
3) I want cascading deletes.

Early proof of concepts show a 100x increase in performance under
load compared to csv. (Yes, 100x not 100%).

>
> Depending on how savvy the users are, you might want to loop this a
> few times to idiot-proof it from a genuinely dumb login being
> requested on a full server.

They are savvy enough to copy the ini file from one install to the
next. I know they will forget to adjust it. If I made a UI to adjust
it, that will just cause support calls as they may not be sure which
one they want.

>
> Other ways are an ini file or a Registry entry that you include in
> your installer or that can be set interactively from a small GUI

app

> that is run afterwards by whatever "responsible" being is

installing

> the software. That would be my preference, since it covers all
> installation possibilities.
>

You could end up with the embedded engine used as a normal client to
a normal Firebird SS or CS. This is fine providing the version is the
same. It is possible that they may have some older (or newer in the
future) version of the Firebird service installed, and this client
library mismatch may cause problems.

To keep it simple, I prefer to use embedded if that is what they
provide and the environment supports it. Using the full server for
this application is a fallback to overcome an environment limitation.

Hmm: This may be what I want.
GetSystemMetrics(SM_REMOTESESSION)

I will investigate.

Adam