Jim, All,

J> The Vulcan/Firebird/Interbase/Rdb architecture specifies only a database
J> filename string.

<SNIP>

that's why the current services API is the way it is, I guess (mind
you, I am talking about the interface here, not the implementation
which is being discussed in a different thread). In the services API,
a conventional "service_mgr" name is used to identify a special
provider (in Vulcan terms) that offers node-wide services. Could this
concept be re-used to allow SQL-based db-less operations in the
current architecture? I think it should be possible: first you attach
to a conventional database name, which gets you a "bogus" database
handle, then you send statements to it. Most probably, you'd need to
get a "bogus" transaction handle as well before you can send
statements. The special provider that gave you that bogus database
handle will know how to handle the administrative SQL-like commands
you send through. Does it make sense?

J> It's not at all clear how you would suggest we connect first to a
J> server.

My 2c: I'd like to keep this unique characteristic of Firebird
(I mean the absence of the concept of a "server") as I find it
terribly good design. We're going to drop the "choose a server, then
a database" idea from FlameRobin as well in the next release.

Ciao
--
Nando Dessena
http://www.flamerobin.org