anyone with a single record and a single user-- should move to SQL
Server.

Access isn't reliable enough for a single user nor a single record.

I won't put up with your bullying.

re:
-----------------------------------------------------------------
I can't image any responsible DBA doing that. DNS records are used to
publish domain and mail server IPs, and that's it.
-----------------------------------------------------------------

Please apologize-- because this link demonstrates your lack of
knowledge:

------------------------------------------------------------
http://blogs.techrepublic.com.com/networking/?p=460

The DNS CNAME record is probably the greatest tool as an
administrator
that we can use to facilitate moves and changes in the backend when
using Active-Directory integraded DNS. Using the CNAME record for
database connectivity is a new strategy I have started to use to
facilitate server moves simply with the DNS change. Take the
following
example:

FQDN Server Name:  DATASERVER1.AMCS.TLD
Associated CNAME:   CORPDB.AMCS.TLD

Now, DATASERVER1 is a Windows cluster for Microsoft SQL Server with a
disaster recovery site with the databases mirrored. If that is needed
to be used, the CORPDB record points to DATASERVER2 to redirect
client
traffic to that database server. But, the management does not stop
there. This accomodates for a single change in DNS to point the
server
in question to the remote data center (RDC) database engine as a
different FQDN name. But, I’ve been taking this a step further with
CNAME use. For each database, I have been creating a CNAME record
that
points to the relevant server or DNS CNAME that the database is
currently housed upon. Further, I make these CNAME records self-
documenting in their nomenclature so that looking at the DNS records
tells you everything needed. Here is an example:

Associated CNAME:   DB-DATABASENAME-STATE.AMCS.TLD
FQDN server name of target host:  CORPDB.AMCS.TLD

In this example, DB indicates a database, DATABASENAME would be the
application name and STATE would refer to the implemenation level
(Live, Test, etc.). All of these relevant records starting with DB-
helps in alphabetical sorting in the DNS console. By using CNAME
records in this fashion, all client connectivity is pointed to the
DNS
record instead of the server name. This permits a move of the server
and a move of the individual database to be transparent of any
configuration outside of DNS record management. By pointing all
client
connectivity to the CNAME record, configuration changes are not
required (other than clearing a DNS cache) on the clients accessing
the databases.
---------------------------------------------------

re:
I certainly wouldn't even consider it for
any database with under a hundred users.

you mean.. if you had 99 users, then you would just run around and
change the server names (IN FOUR DIFFERENT AREAS) on 99 different
desktops?

that sure sounds to me -- like you don't know WTF you're talking about

-Aaron