Back in the late 90’s, tools and languages such Powerbuilder/PowerScript, and Borland’s Delphi/Pascal were leading the pack in the race to R.A.D. (Rapid Application Development). Microsoft, seeing that it had no real poker in this fire decided to push one of it’s products as a competitor, even though it clearly wasn’t. Visual Basic became Microsoft’s (hoped) Giant Killer. But the other tools were complete integrated development environments that encapsulated all the ancillary functions and features of a rich development encironment, such as report writing, databound forms and controls (that were easy to use), source code management, etc., all built-in within the package.
Visual Basic was seriously lacking in a lot of the task automation and other features I just mentioned. It was a language, primarily, and a forms and report designer almost as an afterthought. But they (Microsoft) kept pushing Visual Basic as an alternative to PowerBuilder, when it was never any such thing. And all the while, back at the Microsoft ranch, the real contender was stabled and getting no attention: Microsoft Access.
Access was, and has been from the very beginning an complete package comprised of
- a capable database (for small to medium tasks), a swap-out database engine that would let you pull out the default engine and drop in the industrial strength SQL Server, or any other heavyweight database for which there was an ODBC or OLEDB driver – and there are many),
- Built-In, enforceable RI (Referential Integrity) with full support for cascading updates and deletes, even before SQL Server had them,
- a visual query designer with click-n-use aggregate functions, sorting, grouping;
- a very, very powerful forms designer that was supremely focused on data-bound controls with an extraordinary event model that allowed you to step in at almost any point to add custom code, and full support for sub-forms (all with their own complete event model embedded within the main form)
- a fully fledged report writer that was at least the equal of Crystal Reports at that time, that also supported subreports and a decent (if not as rich as forms) event model,
- An early stab at Web Enabled forms which was utterly worthless and ignored by everyone, including me,
- a full compliment of Macro features even though most serious developers such as myself never used them, but opted for inline code instead.
- And a source code repository where all your non-form bound code could reside in multiple modules, all in one easy to manage place, and, perhaps best of all,
- All this was packaged inside a SINGLE file, making deployments a snap! In the most complicated scenario, you may have (golly) TWO files to manage when front-end code, forms and reports were put in one file, and database tables in another to make updates as easy as replacing a file.
The early versions of Access had some propblems with database corruption whereby your day might end with you lamenting and muttering something about eggs and a basket, but most serious developers knew all the traps and pitfalls and how to avoid them, and how to recover from such problems while we waited for MS to solve the corruption problem – which, by and large they did with the advent of Access97, which greatly reduced the incidence of corruption.
So, by the time we hit the late 90’s, Access was a very stable, very able product. The criticism that it was suitable for more than about 5 concurrent users was only really true if using the default (built-in) Jet database engine. But once you yanked that out and dropped SQL Server linked tables into a backend Access Database, it was smooth sailing, and I often had Access solutions that served 20 to 50 simultaneous users with relative ease, suitable performance, and no corruption. And deployments remained as simple as “here, take this file and save it on your desktop, then click it and… Bob’s your Uncle!”
But Microsoft, for whatever bizarre reason, kept pushing Visual Basic and left Access to languish. And, of course, VB was not, and never was suited to the task of being the PowerBuilder Giant Killer. VB is now as dead as PowerBuilder, but the new tools making the rounds today are themselves calling for a Giant Killer, and this time, Microsoft seems to be giving Access some much belated love.
Access 2010 now integrates some of it’s features directly with Sharepoint 2010 via SP Access Services. And that early attempt at Web Enabled forms is back, this time with much better success in the form of Web Deployable solutions that can be published directly as a Sharepoint Site.
Microsoft, it seems, never really gives up on a product – sometimes even when they should. Who of us would have thought, back in the mid 90’s that that God awful product “FrontPage” would ever come back from the grave once MS abandoned it suddenly and without a clear migration path. Instead, they gave us early versions of “Expression” as a supposed replacement. But all the while we thought FrontPage was smouldering in it’s grave, MS was in fact, pumping it with Steroids and raising it up on a metal platform in the middle of electrical storms, cryinging “It’s alive! It’s alive!… We shall call it Sharepoint!”
And Sharepoint has dominated corporate America’s document management portal ever since.
And now, with the advent of SP Access Services, Access is getting a very, very rare second chance to become a unified, consolidated, integrated development package that integrates with one of MS’s most intractible and difficult to work-with platforms.
I for one am having a grand time playing with all the possibilities, building Access hybrid applications that combine local data, SQL Server data, Sharepoint data (Lists, document libraries, sites, etc) all in one central location again.
So, here’s to hoping that MS grabs this opportunity by the horns this time around.