I was recently working on a problem where the clients were encountering errors generating a report. The report worked for years but several months ago it started failing. This client doesn't have any developers working on the software and the software hadn't changed in over ten years. I have lots of things to say about this situation, but let me get to the point I want to make. I told the client that the problem was in the database. This is a logical conclusion since the code hadn't changed but there were other known problems with the database. Their view of the best way to solve the problem, therefore, was to compare the database to the working backup from several months ago. Although this sometimes works as a debugging strategy, I've seldom found it successful without some idea of what is causing the problem. Since users are entering data on a daily basis, just comparing the databases would be like looking for a needle in a haystack without knowing what a needle looks like. Instead, you have to start with the code that's reporting the problem and determine why it's reporting a problem. From there, you can move backwards to tell what caused the system to get into that state. When you don't understand why a system is misbehaving, it's almost always best to start with the problem.
Download