On Sat, 23 Apr 2005 17:21:25 -0400, Jim Starkey wrote:

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

Yes.

> What problem does this
>solve?

Separating both, you can fire database-less SQL against the
server. Such as administrative tasks like setting up server
wide settings, create databases... Done via SQL with no need
of a database attach.

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

You just don't need the path or the alias. How you specify the server
continue defining the network scheme used: //server/ (NetBEUI), server:
(TCP/IP)
or local (local connection).

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

No trouble. ;-)