I don’t think it is my imagination. I am thinking that the state of custom database development has deteriorated. With a few exceptions, most “casual” Windows database development has been relegated to Microsoft Access, with a little FileMaker thrown in for good measure.

Microsoft abandoned their middle-tier desktop database, Visual FoxPro, back in 2004. There is still an apocryphal claim that there are more lines of xBase code (the underlying programing language for FoxPro) used in currently running applications than there are for all others except Cobol.

Microsoft still has two families of database products; Access, which comes as part of Microsoft Office Professional, and SQL-Server, which is available in a number of flavors running on individual desktop machines to providing back-end support for massive on-line databases.

Why the lamentation? I’m currently working with two NGOs, with different backgrounds and experience, have the same issues regarding their organizational data.

1. They want their data to be all one one place. Organization A. has donors, volunteers and clients, and any single person could be one or all of these things to the organization. They want to look up a person’s name and tell, on a single screen, the full “transaction” history of their relationship with the person, as well as different demographic data related to each person’s “role”. Organization B. has a similar situation, but with even more possible roles, singly or combined as well as several unique roles, including membership in one or more of over 30 committees.

2. They don’t want to learn something new. Organization A. is on its third iteration of a relationship management database. The first was custom programmed over the course of eight years in tiny increments. It was shaping up to be a pretty good information management system, before their state overlords decreed that they would have to use a web-based system imposed from the top which provided the state with outcomes data, but which left out much of the “management information” needed for the organization. They used Telosa’s donor system for awhile, and then switched to DonorPerfect with some custom modifications to accommodate tracking of volunteers. The outcomes data stays with the state’s web-based system. It goes without saying that the two systems don’t talk to each other.

Organization B. has all of its data in Outlook 2007 running on Exchange 2008. They use Outlook to generate as many mailing lists and lists for management as possible. They use a third-party eMail list service, and still keep large chunks of custom data in Excel spreadsheets. But a lot of data is in more than one place.

3. They don’t want to spend “a lot”. No, let me rephrase that. They’ve not yet been able to convince themselves that the cost of an online system is going to yield the kind of leverage and value that they believe should be is possible (and which they had already experienced in the case of Organization A). Yet, if they could be convinced that a cloud-based online system, billed per month was going to serve them adequately they might go for it. But they are also concerned about the ongoing reliability of cloud-based system, and, deep down, I think we all are still resisting the notion of paying hundreds of dollars per month to “use our own data….”, as well as being understandably sceptical of being at the mercy of the constraints of an online system. (Exhibit A. QuickBooks Online. The price isn’t unreasonable for a single user at something like $35.00 per month… but it is sloooowwww, compared with QB for Windows. Then again, QB for Windows, the desktop version, requires a $300 per year “update” for the payroll function which, as far as I can tell, basically allows you to download the payroll tables, and support drops off after the third or forth year, requiring an update of the program. Hello QuickBooks 2011.

The expenditure may in fact be similar between the desktop and cloud versions. But the sense of control is different. It is like prepaid cell phone service versus a monthly plan.

4. They tried Access. Took a bunch of classes. Trained the staff. Tried to make it all work. Forms, Queries, Datasets, Reports. Their application is really too complex for Access. (Don’t tell that to the generic pharmaceutical manufacturer a couple towns over that was at one point running their entire manufacturing line on Access.)

So, now, the situation is they want to use what they have and modify it to contain all of the data that is scattered around in spreadsheets and other systems. Our problem is to accurately assess how malleable each application is, in terms of opportunities for customization, and then, hopefully, adjust our expectations accordingly, and figure out viable options.

One thing is that I think there are ways to improve the situation, even if they are hidden from the desktop user, and incorporated into the existing applications under the covers. Like all Microsoft-based products there are a dozen different approaches, languages, and back-ends to approach the problem. The solution may even include… Access.