Fabricio Araujo wrote:

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

That's a rather terse answer. Could you explain how you propose to back
up a database without identifying the database? You seem quite sure
about what you don't like. Perhaps you could elaborate on what you do
like...

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

Perhaps I've missed something important, but there are not server wide
settings, so I'm not at all sure what utility setting them might
provide. Create database is quite simple and handled adequately by the
existing architecture. For example, if you wish to create database A on
node B, you might try using the database identification string "B:A".
It does seem to work, as it has for a little over 20 years. But perhaps
you have something more profound in mind.

So, please explain what it is that you haven't been able to do (or
figure out).

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

You are familar with the concepts of concatentation and decomposition?
As in, give a node A, a database B, and a designated punctions ":", the
a full identification string can be written A:B, and given a string A:B
and a known punction ":", said string can be decomposed to the nodename
"A" and database "B".

Another point. Given a network "//server", how do you propose to
determine whether to talk to a server on "server" or open a database as
file the file "//server/database"?

>
>
>
>>I do hope you don't consider questions to be flames.
>>
>>
>
>No trouble. ;-)
>
>

Well, I do have a problem. I consider the practice of label contrary
opinions, a priori, as flames to be a rather disgusting.


[Non-text portions of this message have been removed]