On Sat, 23 Apr 2005 21:01:48 -0400, Jim Starkey 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...

From my POV the concept of backing up a database doesn't really need to
be done on database *context* (one that each SQL must be inside a tran-
saction) but on a server context. So:
BACKUP DATABASE A:db1 to db1_23042005_2305.fbk
RESTORE DATABASE A:db2 FROM db2_23042005_2305.fbk
etc (these are just examples)

will run on a server context... Since these are transaction-less SQL
extensions
why complicate the thing dispatching it from a db context?
Same to CREATE DATABASE. No need to be parsed at client library, just
send it to
the SERVER. If it's on the wrong context, give a error message.

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

My idea is allowing for SQL extensions for administrative tasks run
outside
the database context.
All FB conectivity interfaces that I had touched have a strange break
of concept when you need
to do certain (ServicesAPI, creating databases, backup/restore)
things... Because you need a attachment
to the server without need to be connected to a particular database.
And there's
no elegant way to achieve this actually... I gave a look in the API to
do this
and not liked what I saw...
My concept is: you have connection. This connection could be only to
the server to
do administrative things or to a database to do the day-to-day tasks
(inserts, deletes, updates, create/drop tables, blablabla).

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

What I don't like much is that you NEED to be connected to a database
to do things that do not need of a database context.
So, to create a database (among other things):
1 - Connect to *server*
2 - Issue the command

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

I'm lurking on IB and FB lists in the last 7 years and
read every post on the Architect list from day 0.
Not happen all the time, but happen the way you expose
your opinions are very irritant and flame attactive...
Thought I learn a lot from them...
I don't give value to flaming.. Only tech conversation
and the attempt to get good concepts and ideas to be
implemented in a decent and elegant way.
So, let's work and forget this talk that is
getting too big for nothing.