At 11:42 AM 12/04/2006, you 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.

In both the MySQL and SQLLite cases, your code is creating
directories and connecting to files, since that is the physical model
for ISAM "databases". Firebird (whether being used in the embedded
or the server model) is a horse of a different colour and size. You
should use the right horse for the course, i.e. if what you actually
need is to be able to connect application code directly to the
physical data, use MySQL or SQLLite, since that is what they are
designed to do.

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

On POSIX platforms, that is the case. The libfbembed.so client
library on Linux, etc., literally does connect your code directly to
the database, and a special flavour of SQL (called EmbeddedSQL) is
used. Block of this ESQL are recognised by the preprocessor (gpre)
and precompiled into macrotised C statements right in your application code.

On Windows, that model of embedding is not available. FbEmbed.dll,
like libfbembed.so, encapsulates both a client and a single server
process. However, while the Windows implementation runs a
single-thread Superserver, the POSIX implementation runs a single
Classic process.

>On the other hand, I had been working with database for the last 20
>years from involving all majore commercial databases. If I have
>trouble getting started with Simple Stuff, the rest of the new users
>will probably have a much more difficult time.

If you were developing on a POSIX platform, the embedded architecture
is more adept to the "embedded application" model that you are trying
out with the ISAM databases.

On Windows, a more suitable starting point with a client/server
engine is with a client application and a running server, mainly
because of the exclusive file write lock requirement that the Windows
platform makes necessary.

>I will give it another couple of hours try tomorrow so I can make the
>sound decision to which embedded database engine to use.

If your background in databases has always been with engines that
operate on database objects as physical structures, it's possible
that it's going to take more than a couple of hours to get your head
around the client/server model. If you are confined to Windows and
your requirement to have your application code connect directly to
tables-as-files overrides issues such as referential integrity,
transaction isolation and server-based code execution, AND you have
only two hours to decide, then stick with the ISAM databases. Better
the devil you know than the devil you don't.

./heLen