I keep hearing that developers aren’t using Access to create commercial applications anymore. That might be true, but you wouldn’t know it by me.
One thing that I keep being asked to do is review Access applications that developers are preparing to market commercially. I’ve seen three in the past three months, and they’ve all been very interesting, ranging from sophisticated service billing systems to specialized legal office management. There are lots of benefits to this side of my business: I get to meet some interesting people, I get to talk about Access with people who care about it, and I probably learn as much as I help. There are benefits to readers like you, too, as these developers can often be convinced to write up some of the techniques that they use for Smart Access.
It’s not unusual for articles in Smart Access to reflect the work of developers creating and supporting commercial applications. Hardin Brothers’ article on managing broken references in our July 1999 issue is one example, as were Stuart Kinnear’s articles on installing Access applications (in the February, March, and April 2000 issues). Lately, Doug Den Hoed has been sharing the techniques that his development team came up with as part of creating their knowledge base product.
You can check out their product (called The KB™) at www.thekb.com (you can also download a 15-day free trial version). I think that it’s a very interesting tool with one major drawback: It’s hard to describe. The simplest description is that The KB lets you track information about your development project. The most complicated description is that The KB lets you build a knowledge base about your project.
The goal of The KB is to gather together in one flexible storage mechanism all of the information that you need to manage a development project and allow you to access it dynamically. As the project changes, The KB’s users can quickly update their information to provide a dynamic and accurate picture of where the project is and where the project is going. That description makes The KB sound like a project management system, but it aspires to be more than that.
In addition to tracking the progress of your project, The KB also provides a place to record design decisions, who made the decisions, the process that led to a particular design choice, and much else about the project. A team that uses The KB should be in a better position to visualize their project. Described that way, it’s hard to imagine any large project doing without those services. With the information gathered together in one flexible location, new team members can get up to speed faster, existing team members have a common reference source, and future teams can learn from the project’s successes and failures.
Doug and his team have explored a lot of innovative techniques in building their application. Doug’s article in last month’s issue on using GIFs to manage the overhead of using graphs is one example. His contribution this month on using comma separated value (.CSV) files is equally interesting (I’d never have thought that there was a use for comma-delimited files before reading Doug’s article). Next month, he’ll return to show how to create Gantt charts from Access data.
The coding techniques that The KB pushed Doug to develop are neat. What really interests me is the breadth of data that The KB must try to manage. There’s a tremendous amount of disparate information that must be stored. To put it another way: It sounds like the perfect application to be developed in Access. To my mind, Access remains the preeminent rapid application development tool for creating the front end for databases. In the past, Access has really only worked well with the Jet database (so much so that “Jet” and “Access” are almost synonymous). With ADO and the changes that have begun in Access 2000, we might see Access become the best tool for creating a front end for any database.