At 09:05 AM 18/01/2007, you wrote:

>I am trying to create a new Firebird 2.0 database from within my
>application visual basic 6.0 source code. I can accomplish this with
>no problem using ADO provided there is a database to open. Code snipet:
>
>'Firebird SQL - Windows connection string
>cnBase = adoConn.FirebirdSQL_Server("192.16x.x.xx", "Employee.fdb",
>"C:\Program Files\Firebird_2_0\", "SYSDBA", "masterkey")
>
>cnBase.Open

Your "cnBase" object isn't a database. It's a client-side container
for a database connection. Whether you are going about this the
right way I can't tell as I don't use your particular choice of
interface...but isn't this question for a forum that specialises in
the data access interface that you are using?

>Now that I have a database open

You don't "have a database open" yet. Somewhere in your interface
rules and structures will be hidden code that initialises a bunch of
stuff to prepare for either connecting to a database or, as in your
case, for creating one and connecting to it. Your interface's "open"
method presumably performs all this stuff. Other interfaces do
similar things using different code symbols.

>I can create a new one using this code
>snipet:
>
>'Create a new database
>sql = "Create Database '192.16x.x.xx:C:\Program
>Files\Firebird_2_0\test.fdb' user 'SYSDBA' password 'masterkey'
>PAGE_SIZE 8192 DEFAULT CHARACTER SET ISO8859_1"
>
>cnBase.Execute sql
>
>I can then continue by adding tables, etc. The problem is that a
>database must exist before the new database can be created.

You are seeing a problem that is not there. The Firebird client
library presents an application programming interface that defines a
huge number of functions, with associated C structures, that need to
be populated to find the database and perform operations on
it. Application languages (other than C) can't talk directly to this
interface, so you use an interface layer that provides versions of
these function calls and structures that can be understood by your
programming language.

For example, I write client applications in ObjectPascal. I use an
interface layer called IBObjects, which provides complete wrapping of
the Firebird API in the form of classes and methods in
ObjectPascal. In that way, I can use the data access structures that
IBO creates in my programs in ways that ObjectPascal uses data access
structures.

VB doesn't have any such dedicated, direct interface layers as are
available for ObjectPascal, but it does support some generic DA
standards, such as ADO, JDBC, etc., etc. Your VB code can talk to
ADO but ADO needs another layer to talk to the Firebird API. Here is
where drivers come in. They provide this link between the generic DA
structures and the Firebird API.

Actually, for JDBC, Firebird has Jaybird, which is a
fully-implemented, self-contained Java interface that gives Java
programmers a direct layer between their Java code and the Firebird
API. The effect of the Firebird .NET providers is similarly
efficient, although more bulky. There is a Firebird driver for
ODBC....and so on.

In each case, the function calls and structures required by the
Firebird API are implemented ultimately in methods and members that
your local language can work with....so your "database" structure is
not a database, but a set of client-side stuff that describes the
database that the driver is going to connect to. In the case of ADO,
which doesn't support transactional databases, it will also
incorporate the language local interpretation of a transaction. Your
"open" call presumably creates all of these pieces and waits for a
call to either create a database or connect to one.

>I have tried using several iterations of the following code snipet:
>
>msgRetVal = Shell("C:\Program Files\Firebird_2_0\Bin\isql CREATE
>DATABASE '192.16x.x.xx:c:/Program Files/ONFIRE.FDB' user 'SYSDBA'
>password 'secret' DEFAULT CHARACTER SET ISO8859_1;", vbHide)
>
>Can someone help point me in a productive direction?

Depending on exactly which driver you are using, subscribe to the
appropriate list forum for that driver. There is a firebird-vb list
that isn't very active, but you might find someone there who could
help you solve some weird, VB-specific problem; there are
firebird-odbc-devel and firebird-net-provider lists that are very
active, supporting drivers that are constantly under
development. Find details and subscribe instructions at
http://firebirdsql.org/index.php?op=lists

./heLen