A client contacted us about a custom application we’d written two years ago and modified sometime this year.  Apparently, the client had finally decided to run the application (they paid us for the modifications months ago), and it failed.  The developer who made the modifications is either on vacation or no longer with us (I haven’t yet determined which developer made the changes), so it falls to me to discover and fix the problem.

It turns out that the program is a Microsoft Access application designed to run on the client’s Windows 95 system.  The developer who made the modifications was working on a Windows 2000 system.  The modified program works fine under Windows NT and Windows 2000, but fails under Windows 95.  Why?  Because there are incompatibilities between the Windows 95 and Windows NT versions of some common controls, and the Access application retains information about the control set that was on the development machine.  Granted, the developer should have tested the program on Windows 95 before shipping it to the client, but still—an application depending on information about the development system is a really bad idea.

To make matters worse, when the program is run on Windows 95, Access displays a very unhelpful error message:  “There is no object in this control.”  It doesn’t say which control.  Worse, when I try to edit the application under Windows 95, I get the same error message and it still doesn’t say which control has no object.

This (and similar problems) is why we no longer create applications with Microsoft Access.