> As I mentioned, there are some database engines (e.g. SQL Server,
> MySQL) that will in fact do this (subject to the login credentials.)
> For example, you can log in to MySQL with NO current database and ask
> it to enumerate the databases you have access to with your current
> credentials. SQL Server has similar functionality (heck, it will
> even list SERVERS on the network using your domain credentials).

Unlike the other engines you mention, Firebird has no concept of
database registration. Any file on any locally attached drive can be
connected to as a database (subject of course to DatabaseAccess
setting in Firebird.conf). If it is not in a valid file format, it
simply wont connect.

Aliases.conf is simply a method of abstracting the file system
location from the client connection string, so that the DBA can move
the database file(s) around the file system as appropriate without
reconfiguring all the clients. There is no requirement that a database
be even registered in aliases.conf. (unless you have set
DatabaseAccess=None)

>
> Firebird requires you to specify a database as part of the
> connection, and I was just wondering if there was any MySQL-like
> functionality at least for enumerating the aliases by connecting to
> the server without specifying a database. It appears that the answer
> is no, which is fine, but other engines have this functionality.

But other engines require you to tell the server which files it can
use before using them, and also you need to define for the server
which users have access to which database. That does not make is
necessarily easier, it just moves the cost of registering to the
initial setup.

In Firebird, user credentials are controlled by the server, but user
permissions are stored within the particular database. Without some
form of registration of the database to a server, I can't see how it
could be achieved. I am not arguing about which approach is superior,
there is some merit to a centralised registration, but it is no less
work (and on occasions is more work).

> Whether or not it is advisable, customers may be used to such
> niceties and get cranky if they are not provided when the underlying
> db supports them...

You are free to simplify this for your customers by writing your own
custom service that returns the aliases. Perhaps a better approach is
to have a separate file where the DBA can add a list of public aliases
(so it is only configured once per customer rather than for every
client workstation). Adding a line to a text file is probably much
simpler than the registration routine they would have to go through
for MS-SQL or MySQL.

Adam