A CName or Canonical name is the fully qualified domain name and has nothing
at all to do with a particular server other than being listed by a
responsible DNS server. ALL servers within that domain share that CName. If
you are an enterprise with a large number of users (many times more than
would ever be using an Access database), it might save a slight amount of
time to create a CName of a database server, or for a cluster of servers. I
wouldn't bother for a single server which hosted less than a few hundred
user connections. The performance hit for it to resolve a CName, especially
on a LAN is totally unnecessary. I certainly wouldn't even consider it for
any database with under a hundred users. The technique that you mentioned is
new and untested by more than a few, and I doubt that you've ever seen a
first-hand implementation. If you'd bother to look, this is an Access forum,
where most questions have to do with less than 20 users. It is NOT a
SQL-Server forum, although we can and do answer relevant questions
concerning structure and connectivity.
The reason you are here is more than likely the SQL-Server experts have
roundly laughed you out of their newsgroups. The Access experts are doing
the same. Reading a new technique and spouting unrelated answers is a waste
of your own time, as well as ours. Do something useful for this newsgroup or
go away.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com
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.
