The Access Developer's Dilemma

A Brief History of Time Wasted

In late 1992, Microsoft released  Access 1.0, its first attempt at a desktop database application. for the Windows operating system. My initial excitement was soon tempered by massive disappointment: there was a lot to like, but Access was little more than a toy. In 1993, Microsoft released Version 1.1, primarily to make Access compatible with other Office offerings, but far more significantly, to introduce the ability to write code in Access Basic. This version was chock-filled with bugs, and I recall being torn between the tried-and-true Clipper language, even though it was DOS-bound, and what was clearly the path to the future, Windows. But after about a month of frustration, I tossed Access 1.1 into the junk pile.

Later that same year, Microsoft released Windows 3.1 and along with it, Office 4.3 Pro, a suite of applications including Word, Excel, PowerPoint and Access 2.0. Although not without problems, this version of Access made developers sit up and take notice. Back then, your average hard disk could store about 10 Megabytes of data – laughable by today’s standards, but back then it was a big deal, and even though this ruled out anything that might be considered a serious database, there was plenty of room for the power users who would eventually become paid consultants, writing custom database applications for small business. Back then, it was even possible to regard Microsoft as leading the way for developers – providing a database system easy enough for amateurs to try, and inevitably make mistakes, and paving the way for developers to come in and redesign their amateur efforts. Indeed, a market was born, and before long freelance programmers were trolling for contracts doing custom database development in Access.

In 1995, Microsoft released Windows 95, a huge leap forward: the move to a 32-bit operating system, and a complete revision of the graphical user interface (GUI). Beneath the pretty giftwrap lay something much more powerful and intriguing to developers: the introduction of Visual Basic for Applications (VBA), a game-changer. Both Windows 95 and Office 95 had problems, certainly, and hindsight suggests that Microsoft had finally figured out how to make users pay for beta releases. In 1997, Microsoft released Windows 97 and Access 97. Both were unqualified successes.  With Access 97, it became possible to consider serious database development.  Indeed, “The Access Developers Handbook”, by the soon-to-be-legendary three amigos, Paul Litwin, Ken Getz and Mike Gunderloy, was a huge success, and led the way for many thousands of developers to do some serious programming in VBA.

On the operating system front, Microsoft released Windows 98, the truly lamentable Windows ME, and eventually the much more stable Windows 2000/NT. On the applications front, Microsoft released Office 2000, and with it, Access 2000. If Access 97 was considered a game-changer, the Access team outdid itself with Access 2000. Perhaps the most notable feature, from the viewpoint of professional/serious Access developers, was its integration with SQL Server 2000. Access introduced a new type of file, called Access Development Project (ADP), which provided transparent access to SQL Server databases. At the time, I was learning to program SQL databases, and was satisfied with Enterprise Manager, the GUI used to administer SQL Server databases. I remember with shock and awe how superior Access ADP was over Enterprise Manager. The ADP format gave developers full access to tables, views and stored procedures within SQL Server. 

Thus began my deep dive into the world of SQL databases, from a springboard I was already expert at, Microsoft Access. It was a marriage made in heaven. At the time, I was employed by a very specialized and highly successful travel agency, where the initial application I developed blossomed into a full-fledged enterprise application, used by over 70 employees simultaneously, running four branch offices scattered around the continent, all connecting to a server running Terminal Services and housing a SQL Server database. It was a thing of true beauty, and remains one of my proudest achievements. There were problems, of course, but they were all caused by the success of the application and the company itself. For several years in a row, sales doubled, and I, as the sole designer/developer and database administrator, enjoyed something approximating star-status in the company.

The next release(s), Access 2003 and Access XP, consolidated the gains made by Access 2000, even among the so-called serious database community, which was already using Access as a reporting front end for “serious” databases including SQL Server, Oracle, Sybase and others. Indeed, one of the beauties of using Access in this capacity, besides the Rapid Application Development (RAD) it afforded, was the portability of skills and code. Thanks to ODBC, an Access developer could write a custom front-end application, and change the back end from SQL Server to Oracle or vice-versa simply by changing the connection string.

But then, the Access development path began to lose its way. (Some would say that the very success of Access held back the big-picture game plan of Microsoft – that Access was meant to be a toy, from which serious developers would migrate to more serious and expensive tools such as Visual Basic 6, C++ and eventually, Visual Studio and Visual Studio.NET.)

Access 2007 and 2010 seemed to confirm this perception among developers. Access 2007 introduced a whole new interface (the ribbon) and provided numerous enhancements, almost all of which were aimed at end users and almost none of which addressed the needs of developers. Rumours began to circulate among the Access developers’ communities that Microsoft had semi-officially abandoned Access developers.

Where to now, boss?

Access developers were (and are) faced with a dilemma: there seems to be no future in continued Access development.

• Microsoft appears to have abandoned this community.
• The alternative provided by Microsoft, Visual Studio.NET, is by anyone’s standard,  large and complex (perhaps not as large and complex and unwieldy as Java has become, but that is another story). Even with professional training and years of experience programming in other environments, a developer has little to no chance of becoming genuinely productive (e.g. able to bill for hours worked) in less than a year or two.
• The world is moving rapidly away from desktop applications to web-based apps.
• If all this were not enough, now the developer is faced with the problem of developing apps for smart phones, tablets, and other new technologies.

There still exist opportunities for Access developers; but no one can deny that the pool is evaporating, and rapidly. As a professional Access/SQL developer who is well-known in the community, I can readily attest to this. Many of my colleagues all over this continent and around the world, report much the same story. Some are lucky enough to be employed in organizations whose managers are patient enough and foresighted enough to finance the further education of their developers. Most Access developers work freelance, however, and time spent learning C# or VB.NET, not to mention programming for the Web and for smart phones, etc., is time spent not earning money to pay the bills.

I know a few developers who have bridged the gap by taking evening courses in C# and/or ASP.NET. It’s a legitimate path and sure beats running on the spot, but the path to billable hours is even longer this way, since it involves only a few hours of learning per week. Still, it’s better than nothing.

Scanning for a New Squeeze

After thirty years of life as a developer, I have experienced a few watershed moments. I began in the world of DOS, first using dBASE II and then moving on to Clipper, with a little BASIC and C tossed into the mix. DOS was my first watershed moment. Before that I had programmed in CP/M, the ill-fated forerunner of DOS.  There’s a famous story about IBM executives planning to meet with Gary Kildall, creator of CP/M, with a deal to buy or license CP/M for inclusion on its forthcoming IBM PC. According to the story, Kildall was too busy flying his plane to meet with the fellows from IBM, who then went to Redmond to meet with Bill Gates. Gates bought the DOS operating system outright for $50,000, and did a deal with IBM giving that company the rights to package DOS on all its PCs, for a per-computer license, a deal that made Microsoft a giant in the software business.

If DOS changed the world of the PC, Clipper changed the world of DOS programming. Ironically, its creator, Brian Russell, was formerly employed at Ashton-Tate, maker of dBASE II, then the dominant PC database. Brian had approached A-T management with his idea of creating a dBASE compiler, but the company saw this as a threat to the sales of dBASE itself, and nixed the idea. How prescient they were! Brian left A-T and joined the fledgling Nantucket Corporation, where he and his team created the first release of Clipper. It changed the world of PC database programming, and stole almost the entire community of dBASE programmers.

Then came the Macintosh (well, first the Lisa), and although I never bought one, it was clear that the paradigm had shifted to graphical computing. Microsoft at last caught up with its initial release of Windows. At the time, I was an acknowledge expert in Clipper programming: I wrote two books about it, plus several monthly magazine columns and several hundred articles on database-related subjects, for various publications. Nantucket Corporation, makers of Clipper, tried unsuccessfully to move into the Windows world with an ambitious product called Visual Objects (later renamed CA-Visual Objects, after Computer Associates acquired Nantucket) – a very ambitious project but ultimately too buggy for serious development, not to mention too great a leap for most Clipper developers.

Other graphical database systems emerged, and I tried most of them without falling in love. I did what I could with Access 2.0, but withheld my full commitment until Access 97. From that point on, I considered myself an Access developer, especially after the release of Access 2000, with its connection to SQL Server and other serious database engines.

Until, that is, Microsoft released Access 2007. I continued to work with it, although most of my clients stuck with Access 2003/XP. But I was determined to learn the new ribbon technology, and grateful that Microsoft had preserved the ADP file format and its direct connection to SQL Server. But I was not alone, by any means, in my queasiness over the future of Access. Many if not most Access developers felt abandoned by Microsoft, and Access 2010 confirmed our misgivings. For one thing, it is riddled with bugs; for another, there is almost nothing to point at that is an obvious benefit to developers. Still worse, the only avenue toward development of web applications lay in a marriage to SharePoint, a very useful product to be sure, but also price-prohibitive for most small businesses, the bedrock of Access developers.

A little while ago, I joined one of the Google+ groups, a community of Access developers, and became an active participant there. Eventually I received an email from Richard Rabins, co-chairman of Alpha Software, makers of a product called Alpha Five, now in version 11. Mr. Rabins approached me, I guess, because thanks to my numerous postings on various Access newsgroups, I have acquired something of a reputation as a seasoned Access+SQL developer. He offered me a free license to Alpha Five v.11, which I accepted.

Since I received my serial number a couple of months ago, I have spent more and more time with Alpha Five v.11. I’m not yet ready to call myself expert, but I have dived headlong into the product and its development language. At this point, I think that I am ready to declare another watershed moment in my career.

In a word, I love Alpha Five v.11. It answers every demand I currently place on a development product:

• 1.       RAD – in spades. You can do significant things more quickly in Alpha Five than in any other development environment I know.
• 2.       Programming language – Alpha Five is built on XBasic, a solid programming language which also happens to be cross-platform. Among its virtues are:

a.       Familiarity – XBasic is a lot like VBA, but more powerful and more concise. Access developers will feel comfortable almost immediately. There are differences, of course, such as slightly different names for events and properties, but these are easily handled.

b.      Classes – XBasic implements true classes, as opposed to the tricky, shoddy, half-assed implementation in Access.

c.       Wizards and Genies – Alpha Five comes with numerous wizards to guide the developer through various tasks required to build an application. Genies are akin to super-wizards: code generators that can build complete chunks of an application automatically, based on the structure of the database. Also worth mentioning are Actions. Roughly equivalent to macros in Access, Actions perform tasks without requiring code. However, they can also be converted to XBasic  code for further customization.

• 3.       Database connections – Alpha Five has its own native database format, but also provides easy connections to Access databases, and ODBC connections to every serious database you’ve ever heard of, and one or two you may not have heard of.
• 4.       Web development – this is where Alpha Five really shines, and frankly blows the doors off Access (not to mention numerous other platforms). At the outset of a project (or for that matter, anytime during development), the developer can choose whether this project is for the Desktop or the web. This choice affects the Toolbox and the tools it offers. The Desktop toolbox will be most familiar to Access developers; the Web toolbox contains a host of web-specific tools and controls. All this will be new to many Access developers, but not to worry: it will all become familiar very quickly.
• 5.       Tutorials – here Alpha Five blows the doors off Access. While Access does provide some sample applications, probably the most advanced is a simple Time and Billing application. Alpha Five goes much further, in both quantity and quality. Its sample apps are professionally designed and coded, not only to illustrate language features, but also to perform real-world tasks. One could take the Alpha Sports application, for example, tweak it here and there, and ship it to a client as a finished custom project. The samples are that good. Besides the sample apps, there are also a number of templates for projects such as invoicing.In addition, the Alpha Five web site provides a collection of video walk-through tutorials to help new developers grasp the steps involved in various tasks.
• 6.       Performance – I’ve tested Alpha Five against Access in several contexts: native/native, Access back ends, and connections to SQL Server and MySQL. In every case, Alpha Five outperforms Access by far.
• 7.       Runtime – this is a significant concern to Access developers. Microsoft includes a free Runtime package that allows the developer to create an application, then deploy it with the Runtime, such that the end user of the application need not have a copy of Access in order to run the application. Alpha Software’s approach is slightly different. Instead of a Runtime, it provides an Application Server, which is included in the software but not free for distribution. Instead, the Alpha developer purchases an additional license, for a modest fee, and then has the right to distribute Alpha Five applications to an unlimited number of clients.
• 8.       Community – as Access developers know, the community is a vital component in successful development. Access enjoys several communities where developers can turn when they have development problems or merely “How do I…?”  questions. The Alpha Five web site provides such a community as well.

Summary

After much looking around and experimentation with several of the development products currently available, I’ve made my choice. I’ll continue to develop in Access, not least because I am frequently called back by past clients who are in need of enhancements to previous projects. But from here on in, I’ll be recommending Alpha Five for all new projects, and I am confident that I can present a strong case for it.

This is especially true if the project has any current or future plans for deployment on the web and/or smart phones and tablets. In that case, there is no contest. Access offers nothing. Visual Studio.NET offers plenty, but at significant cost, plus abandonment of existing code, not to mention the significant hurdle of mastering a completely different language. Finally, while Access maintains its ADP connections to serious databases, this seems increasingly like an afterthought, whose inclusion is merely to placate those developers who’ve made the commitment to master it. Alpha Five on the other hand takes obvious pride in its support of serious databases.

I’m sold, in short. I would strongly recommend to every Access developer faced with the same dilemmas as I was, to download the trial version and kick its tires. I’m very confident that they will be very pleased with this offering from Alpha Five Software. For more information and to download the trial version of Alpha Five v. 11, visit http://www.alphasoftware.com/.

One final thing: Other than having been granted a free license to investigate Alpha Five v. 11, I have no relationship whatever with the company. Mr. Rabins has graciously answered some of my questions by email, but beyond that I have no ties to the company. I was not approached to write this piece, and in no way will benefit financially from its publication.