Maintaining software is a never-ending battle. Even if your program is bug-free and feature complete, you still have to deal with ever-changing operating environments. A new operating system version, for example, might render your program inoperable. Or the vendor might update the database software and cause your SQL queries to fail in strange and wonderful ways. Or perhaps some third party program replaces a shared file with a newer version that is incompatible with your software.
Whenever something like this happens, your customers will call and say “Your program is broken.” They don’t care that the other vendor is the real culprit. After all, the other vendor’s program is working fine while yours is broken. You can try to educate your users, and some might even accept your explanation, but there’s always that lingering doubt in their minds. It’s unfortunate, but true. If somebody pulls the rug out from under your software, the users are going to blame you.
No, I don’t think there’s anything you can do about it.
In today’s case, it was an upgrade to Microsoft’s MDAC (Microsoft Data Access Components) version 2.6 that broke our database access and prompted a user to call the support line. We had tested our software with MDAC 2.5 and earlier, but 2.6 wasn’t available when we shipped the product. I don’t know yet whether this is a bug in MDAC 2.6, or if it’s a bug in Borland’s ADO Express package that we use for database access. Fortunately, Borland had a fix that we were able to download and apply to fix the problem. That won’t prevent the hundreds of existing users who upgrade to MDAC 2.6 from encountering the problem. We’ll notify them of the problem and of the upgrade, but most of them will ignore the upgrade and then call the support line after they install MDAC 2.6 and our product fails. Such is life.
No, this problem isn’t limited to Microsoft product upgrades. We had a similar problem with an Oracle upgrade about a year ago. Things like this pop up from time to time just to keep life interesting, I guess.