Subject | Re: [Firebird-Architect] Create database -> rats' nest |
---|---|
Author | Fabricio Araujo |
Post date | 2005-04-22T22:52:46Z |
I can be saying something stupid,but I think that
the problem is the parsing of the client library.
That concept that you always attach to a database
is the source of that "hack". IMHO, you can attach
to *server* and after specify a database to access
or run a database-less SQL like create database.
Doing that way, the create database statement
does not need to be parsed at client side.
I could be saying something absurd... And all flames
that came from Jim et al will not be taken personally... ;-)
the problem is the parsing of the client library.
That concept that you always attach to a database
is the source of that "hack". IMHO, you can attach
to *server* and after specify a database to access
or run a database-less SQL like create database.
Doing that way, the create database statement
does not need to be parsed at client side.
I could be saying something absurd... And all flames
that came from Jim et al will not be taken personally... ;-)
On Fri, 22 Apr 2005 17:42:01 -0400, Ann W. Harrison wrote:
>
>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'
> USER 'SYSDBA' PASSWORD 'masterkey' PAGE_SIZE 8192
> DEFAULT CHARACTER SET WIN1252
> 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.
>
>Regards,
>
>
>Ann
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>