We have a number of reports in our system. They are written with an old version of Oracle Reports Builder. We store them in RDF format. Recently a customer wanted some changes to the most complicated report we have. The reports developer coded up the changes. The modified report was included in our build to the test team. However it seemed that the test team was having a lot of problems. Our reports developer said it looked like the testers always got an old copy of the report. The reports developer decided the only solution was to turn the RDF report into an executable.That solution screamed of doubt. Our team lead also said he could not imagine that this could be the best course of action. He asked me to assist to find out what was really going on. I said that we could turn the report into an executable. However I strongly encouraged that we understand the cause of the problem first. I am really to busy to spin my wheels on fixes that are guesses. I tasked the reports developer to get to a stage where the problem could be reproduced at will. I said that the testers could duplicate the problem. So this should not have been a difficult task.
Once the reports developer got a tester login, we were ready to move on. I said we needed to find out whether the report that got modified was actually getting called. I told the reports developer to look at a database table which logs the path of each report that we run. Sure enough, the updated report was getting called. I then had the developer look at the logic inside that report. It seemed this report was spawning off another worker report. The report developer jumped at the chance, and modified this report to use another technique to spawn the second worker report. That only caused more errors.
I instructed the reports developer to roll back those changes. Then we continued on. I asked the reports developer to determine whether the second worker report was getting called. Some logging code was added to this report. And yes indeed, the second worker report was getting called. Then I had the reports developer mimic the configuration of how that second worker report was getting called. With that configuration in place, I had the reports developer run the report using the Oracle Reports Builder tool. At once the problem was evident. This second report was expecting a certain table structure in a temporary table. This new structure was supposed to be controlled by an update to a stored procedure. It looks like that stored procedure change did not get promoted to the test database.
What is the moral of the story here? There are a few. The first is that you should not fix a bug that you can not reproduce. You should also not try to code a fix if you do not fully understand the root cause of the problem. Breaking down complex processes into smaller steps helps isolate problems. Old school error logging also helps you get a handle on things gone awry. I hope these lessons get learned with experience. Everybody has to learn sooner or later.
