--- In firebird-support@yahoogroups.com, "Jeff Lynn" <jmlynn@...>
wrote:

>
> Thanks for the quick response. I did read the quick start guide

first

> before attempting to use either mode. It is fair to say that these
> doc sounds clear to you who had already cross the barrier but may

not

> be that clear to someone else entirely new to Firebird.
>
> I was in the process of evaluating embedded database engines,

namely,

> MySQL, SQLite and FIrebird. Within 20 minutes, I was already

running

> C++ examples that connect to either embedded databases (MySQL and
> SQLite). As far as I am concern, the Firbird doc are very much
> unclear when it come to setting up and use. The doc paints a very
> straight forward picture. I even recall I read something regarding
> using the classic database using file that reside in harddisk in the
> same local machine, there is no need for networking connection as

you

> stated.

The database file(s) must be mounted on a volume physically attached
to the server running the database engine. (Not an unreasonable
request considering the amount of I/O between the database engine and
the database file).

Unlike file based databases, the firebird server manipulates the
database on behalf of your application when your application submits
requests.

Your program must therefore make a connection to the database engine.
There are several methods to do this and there are some limitations
regarding which methods work with which architecture on which
operating system.

So if (in a windows environment) you intend on connecting to a
classic database server, your connection string needs to be in the
TCP syntax. To the database engine, it is just another possibly
remote client, although in truth it is just a TCP loopback.

The following is assuming Windows. I have detailed the 3 possible
architectures you can use and what types of connections they accept.

With Superserver architecture:
* Local Connection
* TCP/IP

With Classic architecture
* TCP/IP

With Embedded:
* Local Connection

There is also named pipes but you don't need to worry about that.

Now you plan on delivering it as an embedded engine. Embedded is a
Superserver engine inside a dll. Therefore you will need to adjust
your connection string if you plan on using both embedded and classic.

You would be far better to use the Superserver service because that
behaves the same way (except multiple processes can connect to it and
it can be connected from other machines).

The architectures have the exact same API. The only required change
of code for getting it to work on another architecture is to change
the connection string between

[c:\path\to\database.fdb]

and

[server hostname]:[c:\path\to\database.fdb]

We use an ini file to build the connection string.

Adam