Fabricio Araujo wrote:

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

The Vulcan/Firebird/Interbase/Rdb architecture specifies only a database
filename string. Different pieces of the plumbing treat the name string
differently. The remote interface may try to translate the name string
as a logical name, check to see whether the name string is a symbol link
and fetch its value, look up the name in an alias table, or do other
tricks to discerrn the user's intent. When it has resolved a name
string, the remote interface decomposes by a characteristic piece of
punctuation to network node and and local database name. It then
connects to the named server by the network implied by the
punctionation, and passes up the remainder of the name string as the
local database name. Then the process repeats on the server.

It's not at all clear how you would suggest we connect first to a
server. Are you suggest that drop the strategy of database name string
in favor of separate server and database names? What problem does this
solve? And don't we lose location transparency in the process? How,
your scheme, is the network identified? Or have you decided that TCP/IP
is the only network we should support for the rest of eternity?

I do hope you don't consider questions to be flames.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376