Making More Chalk Marks
Sep. 11th, 2008 05:59 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
billroperAnd with another in our continuing series of "knowing where to make the chalk mark that solves the problem is worth a lot", we find our hero pulled back into a problem at a client. Last week, I looked at a dead file that we'd been sent and reported, "The problem is with the updating of our reports". This turned out not to be quite right, but was definitely a shot fired in the right direction. There wasn't any significant movement on solving the problem, so I was asked to take a look at it again. This time, I moved another couple of shovelfuls of dirt and found an old enemy. Immediately before writing out the reports, our serialization code used to (this is an older version) check the printer settings for each report page and store them away so we could get them back next time.
I've fixed a couple of bugs in the third-party tool that handles this particular printer interaction, so I wouldn't have been surprised if there was yet another bug in the neighborhood. So I suggested commenting out the offending line of code to get the client running again until we could figure out what silly printer driver problem we were having this time. Of course, this meant we had to find out what version the client was running on.
It turns out that the version they're on was so old it didn't have my fixes to the third-party tool. It's a separate OCX, so we sent that to them and the problem seems to be much better now. We'll see if it stays fixed.
In other news, I just sat down with the fellow who wrote our consolidation today and we've substantially simplified the process there in the hope of eliminating some particularly pesky bugs. We'll see how that tests out tomorrow.
And for those of you still wondering how the dam story came out, suffice it to say that our hero took the gun away from the police chief and drained the water out from behind the dam before it could burst.
I've fixed a couple of bugs in the third-party tool that handles this particular printer interaction, so I wouldn't have been surprised if there was yet another bug in the neighborhood. So I suggested commenting out the offending line of code to get the client running again until we could figure out what silly printer driver problem we were having this time. Of course, this meant we had to find out what version the client was running on.
It turns out that the version they're on was so old it didn't have my fixes to the third-party tool. It's a separate OCX, so we sent that to them and the problem seems to be much better now. We'll see if it stays fixed.
In other news, I just sat down with the fellow who wrote our consolidation today and we've substantially simplified the process there in the hope of eliminating some particularly pesky bugs. We'll see how that tests out tomorrow.
And for those of you still wondering how the dam story came out, suffice it to say that our hero took the gun away from the police chief and drained the water out from behind the dam before it could burst.