I was looking for an embedded database engine for an interal daemon
application and advoid dependency on a full-blown database server as
well as simple installation. Prebuilding the database file and then
bundle the database file with the application is good. I just need to
be able to attach the database file and use it for
insert/delete/update/query purpose.

With post from Adam, I can not successfully created the database file,
create a test table with some test records. However, while using
ISQL, it forced me to provide user/password. The consequence is now
my test C++ program failed during the isc_attach_database api call
with error indicating the database requires user/password.

Wonder how you can get around that?

jml

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> 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
>