On 11/8 SafariTECH responded: "Access should never be used
for a production site - it is a desktop database, not a server
database." It IS a "desktop" database and NOT a "server" database,
but that doesn't disqualify it from being used for a production
site.
At our company we have extensive (multiple-year) experience
with Access on the back-end, and if you take the time to understand
its limitations and account for them in your code, it can be used
successfully. When we choose between Access or SQL Server on the
back-end, it is based on expected traffic, ease of maintenance,
footprint, and so on. In most cases we DO end up using SQL Server,
but there are circumstances where Access -- even as a "desktop"
database -- has proved a better choice.
In a recent system we built, access to the web server and
ColdFusion had to be extremely limited upon system deployment. No
VPN, no modem, and a special arrangement with a third party to gain
physical access. To minimize the system footprint while designing
for completely-hands-off, 24x7 operation, we needed a pair of
servers with shadowing and automatic failover if the primary system
died. If we had chosen SQL Server, it would have required its own
server box, and we would have had to double these up as well. This
costs more money and adds yet more complexity.
Given what we knew would be the traffic through the
dedicated, private site with a handful of users at any one time, we
decided that a server-class DB was unnecessary, and in any case,
would force us to add hardware that itself could be a source of
system failure. This was the deciding point in favor of Access.
All aspects of the system that directly relate to Access have
been running successfully, except the issue reported initially by
happysailingguide. We experienced the same issue, which appears to
be a ColdFusion-induced error, and not something inherent to Access
or the fact that it's a desktop database. (Based on what evidence?
We use Access in many automated telephone applications which are
written in Perl instead of ColdFusion, and this problem has NEVER
been seen in the 5+ years of production usage.) In our case it
appears there are NO requests queued to Access at the time of the
lockup, and the lock can last forever unless we take programmatic
intervention.
As anybody who has built and deployed many production sites
knows, you must simply accept the fact that no hardware or software
is error-free (yours or anybody else's). The described Access
lockup is just one of these errors (and is probably pretty low on
Adobe's list of things to fix). With a different DB there wouldn't
be the same problem, but there would be another to take its place,
perhaps increased system failures because of the increased
complexity of the system, or the downside of greatly increased
costs when replicating the system.
When I was trying to decide on the Access vs SQL Server
question a couple years ago, I read the forums and web discussions
about how Access should never be used for a production site. There
were many scary statements about Access that nearly prevented me
from using it. But at the advice of a colleague who has used Access
for several years in a telephony app with 100 or more simultaneous
callers, I stared a little more at the timestamps on the
statements, and found they were from a long time ago (in
computer-years). Microsoft has made MANY improvements to Access
over time. For anybody facing the same decision, you will find it
worthwhile to consider Access if cost, complexity, and footprint
are important factors.
13
Replies
AdChoices