Subject Create database -> rats' nest
Author Ann W. Harrison
Several months ago, Michael Hieke pointed out that if you try to create
a Vulcan database with a Firebird (or InterBase) ISQL and client
library, the following happens:

sql: CREATE DATABASE 'localhost:C:/test.fdb'
SQL error code = -530
-Cannot prepare a CREATE DATABASE/SCHEMA statement

There turned out to be one bug blocking others, which caused a different
error message (unavailable database). The fbclient library calls
attach_database before calling create_database to avoid overwriting
existing databases in old versions that don't respect the dpb parameter
that says, don't overwrite. It looks for an error code of I/O error,
and assumes it can safely call create_database. Vulcan returned the
wrong code: it needed to return the first error it found, and instead
returned the last one. That's fixed and checked in, as is a problem
handling non-terminated SQL strings in Special SQL.

Now, on to the real problem. ISQL passes the create database statement
to fbclient in an execute immediate call. The client library parses the
create statement and creates a dpb. It uses that dpb, plus the file
name, in an attach call. If the attach fails properly (which it now
does), it calls isc_create_database. So far, so good. We get a
database created by Vulcan.

However, the parser in fbclient only checks for a five of the attributes
of the statement - user, password, page_size, length, and set names. If
if finds another attribute, like default character set, it returns a
flag saying that the statement was not completely "eaten". If the
statement wasn't eaten completely, the client library goes ahead and
creates the database anyway, then starts a transaction, then calls
execute immediate with the full statement, and the existing database and
transaction handles.

Vulcan handles the create statement from the Y-valve and not from a
provider because the statement doesn't require a database handle. Now
it also handles it from engine8, if it gets a database handle.