[AccessD] MS Access and data-driven websites

Drew Wutka DWUTKA at Marlow.com
Fri Jun 22 01:18:52 CDT 2007


ROTFLMAO!  I am SOOO glad I don't have to talk to DBA's like the one you
mention.

Using an Access .mdb behind a data driven website is just fine, in fact,
it's cheaper and FAR less resource intensive then any server side db.

What are the disadvantages to Access?

1. No Triggers
2. Weak Security
3. remote users are using file sharing, not server side transactions.
4. No rollback capabilities.
5. Size restrictions

When an .mdb is on a webserver, 1 through 3 go out the window as
disadvantages:

1. Triggers can be built into the business logic behind the website. (Of
course, if this is a dual app, something with a web interface and
another type of interface, then yes, no triggers could still be a
disadvantage, but we're talking about a true web based app.)
2. Once the .mdb is behind the web server, there is no direct access too
it.  Unless you are providing access to the folder the .mdb is located
in (which is poor design), then the security is controlled through the
website and the business logic.  In fact, the security is better then a
server side db.  One of the most basic web based security issues is SQL
injection...which just doesn't work with Access.  To use SQL injection,
you have to be able to comment out parts of the SQL.  JET doesn't allow
SQL comments, thus, no security hole.
3. With the .mdb on the web server, it is no longer being used by
multiple network users.  It is being used strictly by the webserver, so
it will run just as fast and smooth as an .mdb on your local desktop.

So you don't have roll back capabilities.... Yippie skippy! ;)

As far as slow and load bearing, OMG, what the heck?  Given the same
machine power (having a web server with the same power as a web server
and SQL Server combined), an .mdb is going to go just as fast, if not
faster then a SQL Server.

Oh, I forgot another disadvantage.... Memo indexing....an that is
possible with Access, it just involves some creative code.

So when it boils right down to it, the only consideration when building
a web based app, is how much data are you going to store, issue #5.  If
you are looking at adding a gig of data a day, then Access is going to
be problematic.  But most apps aren't going to see the far side of the 2
gig limit for centuries.

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Christopher
Hawkins
Sent: Thursday, June 21, 2007 6:58 PM
To: accessd at databaseadvisors.com
Subject: [AccessD] MS Access and data-driven websites


Hello, all!  It's been a while since I was here, but I had a thought
today that seemed like a perfect fit for the list, so here I am.

Over the past few years I've more or less specialized around SQL Server
and ASP (both classic and .net).  In fact, 90% of my projects that
involve an interface run in the browser now.  But the one place where I
have not been able to escape MS Access has been on small web sites.

Now, I know that the "conventional wisdom" is that using Access to power
dynamic web sites is a bad idea.  In fact, what inspired this message
was a conversation I had with a DBA acquaintance of mine about this very
subject.  He is adamant that it's better to pass on a project than to
agree to use Access to power an asp site.  With him it's SQL Server or
nothing.  He cited all the usual stuff about Access being too slow and
not being able to handle load to bolster his argument.

But, I've had several Access-powered web sites go up over the past few
years.  Sure, it's mostly serving text content, but I've never had an
Access-specific problem with any of them.  And some of them are
reasonably complex on the back-end!  It seems to me that when an
Access-powered site is sucking wind, the problem is more in how the
pages are coded than in how JET works.  It seems simple to me; you don't
grab more records than you need, you close your recordsets, you keep
your connection code clean, you turn off the Subdatasheet property in
the mdb.  Little things like that.  

For my larger clients, sure, SQL Server is the way to go, and I'm on the
road to becoming a SQL Server guru myself, but I don't really see any
downsies to using Access to power small sites.

Is anyone else doing a lot of web work?  Are you using Access to power
your dynamic sites?  If so, let me know what your thoughts are on this.


Respectfully,

Christopher Hawkins
Chief Developer
Cogeian Systems
(559) 687-7591
www.cogeian.com 


--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited.





More information about the AccessD mailing list