OK, here's my take on an aliasing system.

To connect to a database, client applications hold a simple alias name,
e.g.: OurDatabase, and an "alias resolver" machine name/IP address, e.g.:
DbResolver.

The client connects to DbResolver on a well-known port, and present the
alias. The DbResolver returns an error message or a standard connection
string, such as dbserver1:c:\ourdatabase.gdb.

Pros:
1. Little impact on client applications: it's just a step to be done before
connecting; existing stuff keeps working.
2. No changes to existing code base.
3. Very easy to implement on Windows (and I suppose not too difficult to
implenet on *IX).

Cons:
1. An additional port to be opened, an additional program to be setup on the
server.
2. The address of the resolver has to be hard-coded on the client (although
this might be saved with a broadcast).

Things I intentionally ignored:
1. Remote administration. There is *no* remote administration.
Administrators can log in at the server computer and modify a text file, or
use vi/whatever through a telnet session. I'm keeping this simple
2. No security/authentication. Security can (and should!) be implemented at
the database level. If you don't want your users tampering with the database
file(s), keep their hands off the filesystem

I'd like other people's input on this before starting to write anything.
What am I missing? What obvious, glaring holes can you see here?

TIA for bearing with me,

Marcelo Lopez Ruiz