So you’re experiencing a situation where your software is misbehaving. It’s doing something you don’t expect, or even worse it’s doing something wrong. If you’re like the majority of the general population, you’re thinking, “I have to fiund out what's wrong”, then you start digging in. Could be there’s a DLL file that’s the wrong version, or there’s a bug in the code, or there’s a piece of data that’s bad, or, or, or... If you’re not certain about exactly what is causing the problem, sometimes it helps to start ruling things out to determine what’s not a part of the problem.
This can be particularly helpful and effective at the onset of the troubleshooting process, when you’re looking at things at a high level;Is it a problem with the database?A problem with a user? A problem with something I customized?These are all fundamental questions that must never go unanswered.But how do you determine these?Well, how about this: When was the last time the server or the client PC (or both) was re-booted?Now I know, you’re thinking about that Dilbert cartoon where Dogbert says to his caller, “Shutup and reboot!”More likely though, you’re thinking that’s a cop-out, a way to get the caller off the phone without doing any real troubleshooting.Well, let me tell you from a recent personal experience that you should never overlook this one.We had a situation where a SLX Report exported to PDF would preview correctly in landscape mode, but would print in portrait mode and cut off ¼ of the document.We worked on this for two weeks, until the system admin rebooted the server where Adobe was installed.Guess what?The problem went away.The system admin then told us he had installed an update to Adobe Acrobat but never rebooted the server.Made us feel kind of dumb…
So if you’ve re-boot servers (and clients) and the problem hasn’t gone away, you’ve just eliminated a culprit.You know that’s NOT part of the problem, and you probably don’t have to think about it again.The same can apply to narrowing the possibilities down when looking for a root cause.If you think something could be data related, try the same (or a similar) operation on a different database.Perhaps try it on the SLX supplied evaluation database.Does the problem happen there too?If so, you now know the database is NOT part of the problem.If the problem stops on a different database, you dig in to the troublesome database further.What about your customizations?Try taking them out if you can.Does the problem still occur?If it does, then your customizations are NOT part of the problem and you can focus your problem hunting efforts elsewhere.
Remember, if we all knew what the problem was, we would just go right to it and start fixing it.Troubleshooting isn’t always about fixing problems, in fact the hardest part can be finding the problems.Once you’ve peeled away the onion (ruled out all the stuff that’s not part of the problem) you can usually find the root cause, and a fix should then be easy to identify.
In my next blog I’ll talk about a different method (and when to use it) that we refer to as “Divide & Conquer.”