[AccessD] Simple-Talk commentary

This article all sounds nice but the Excel conclusion is crazy. Excel is so
much more limited than Access...

Jim

 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Erbach
Sent: Monday, May 17, 2010 2:10 AM
To: Access Developers discussion and problem solving
Subject: [AccessD] Simple-Talk commentary

Dear Group,

I receive the Simple-Talk newsletter from Red Gate software.  It's a
SQL Server-boosting publication with lots of good articles sponsored
with ads for Red Gate products.

The editorial content is good, too.  This month's edition (out this
morning) had the following editorial and I thought I'd pass it along.
What do you think about the editor's point that there is no obvious
upgrade path from Access and that it has long out-lived its
usefulness?

~~~~~~~~~~~~~~~~~~~~~~~
Editorial: Access Denied

When Microsoft executives wake up in the night screaming, I suspect
they are having a nightmare about their own version of Frankenstein's
monster. Created with the best of intentions, without thinking too
hard of the long-term strategy, and having long outlived its
usefulness, the monster still lives on, occasionally wreaking
vengeance on the innocent. Its name is Access; a living synthesis of
disparate body parts that is resistant to all attempts at a
mercy-killing.

In 1986, Microsoft had no database products, and needed one for their
new OS/2 operating system, the successor to MSDOS. In 1986, they
bought exclusive rights to Sybase DataServer, and were also intent on
developing a desktop database to capture Ashton-Tate's dominance of
that market, with dbase. This project, first called 'Omega' and later
'Cirrus', eventually spawned two products: Visual Basic in 1991 and
Access in late 1992. Whereas Visual Basic battled with PowerBuilder
for dominance in the client-server market, Access easily won the
desktop database battle, with Dbase III and DataEase falling away.
Access did an excellent job of abstracting and simplifying the task of
building small database applications in a short amount of time, for a
small number of departmental users, and often for a transient
requirement.

There is an excellent front end and forms generator. We not only see
it in Access but parts of it also reappear in SSMS. It's good. A
business user can pull together useful reports, without relying on
extensive technical support. A skilled Access programmer can deliver a
fairly sophisticated application, whilst the traditional client-server
programmer is still sharpening his pencil. Even for the SQL Server
programmer, the forms generator of Access is useful for sketching out
application designs.

So far, so good, but here's where the problems start; Access ties
together two different products and the backend of Access is the
bugbear. The limitations of Jet/ACE are well-known and documented.
They range from MDB files that are prone to corruption, especially as
they grow in size, pathetic security, and "copy and paste" Backups.
The biggest problem though, was an infamous lack of scalability.
Because Microsoft never realized how long the product would last, they
put little energy into improving the beast.

Microsoft 'ate their own dog food' by using Access for Microsoft
Exchange and Outlook. They choked on it. For years, scalability and
performance problems with Exchange Server have been laid at the door
of the Jet Blue engine on which it relies. Substantial development
work in Exchange 2010 was required, just in order to improve the
engine and storage schema so that it more efficiently handled the
reading and writing of mails. The alternative of using SQL Server just
never panned out.

The Jet engine was designed to limit concurrent users to a small
number (10-20). When applications outgrew this, bitter experience
proved that there really is no easy upgrade path from Access to SQL
Server, beyond rewriting the whole lot from scratch. The various
initiatives to do this never quite bridged the cultural gulf between
Access and a true relational database.

So, what are the obvious alternatives for small, strategic database
applications? I know many users who, for simple 'list maintenance'
requirements are very happy using Excel databases. Surely, now that
PowerPivot has led the way, it is time for Microsoft to offer a new
RAD package for database application development; namely an
Excel-based front end for SQL Server Express. In that way, we'll have
a powerful and familiar front end, to a scalable database, and a clear
upgrade path when an app takes off and needs to go enterprise.

If you'd like the chance of winning a $50 Amazon voucher, post a
comment on my blog telling me what you think about Microsoft's
Monster. This week the prize goes to Lee for his comment on the 'Need
to Know' editorial.

Cheers,

Tony

~~~~~~~~~~~~~~~~~~~~~~~

Regards,

Steve Erbach
Neenah, WI

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com