Break Problems Down

, 2018-11-19

Recently I was pouring over a few questions in the forums and noticed something that I would think is obvious, but apparently it isn't so for other people. A poster was attempting to run a query across multiple databases and needed help structuring code to work in the context of each database. The poster was going back and forth a few times with others that were attempting to help them, struggling to get suggestions implemented into their code. That's typical, as someone that needs an answer often doesn't understand the solution and is learning. In this case, I found that the original poster was losing some of their troubleshooting skills in the process.

Years ago I read a piece on Simple Talk from Kathi Kellenberger. She is now the current editor of the site, but at that time she was just a SQL Server MVP and expert that was looking to help others learn more. The article was called Solving Complex T-SQL Problems, Step by Step, and it stuck with me. There wasn't any knowledge that I didn't know, but it was an organized explanation of the Kathi's steps that I found refreshing. This was a nice reminder to me to not move too fast, but ensure that I really understand what the problem is and work in stages.

I've certainly been guilty at times of moving too fast and glossing over some details. That might be fine in some cases, but if I produce code that's doing that, likely I (or someone else) is going to be rewriting code later. That's not what we want to do, especially if this is a logical error. I might understand some less than optimal code from a performance perspective, but there shouldn't be logical errors.

In this case, the poster had incorporated some changes into code and kept running the entire script, getting bad results. They even started to pinpoint a few areas where data wasn't correctly being returned, but couldn't solve the issue. This was a somewhat complex script, and it could be easy to miss some mistakes. This was also a dynamic SQL script, which often means that we have to extrapolate from our code to understand what the engine will actually execute. There's often a simple solution to help you break the problem down: use PRINT.

I've done this for most of my career, in many languages. Even today, I sometimes use this in PoSh to ensure that I'm not missing something being done. Watch windows and other debugging tools are great, but they sometimes are more difficult to understand when there are long strings of data. Print often simplifies the process.

No matter what tools, languages, problems, etc. you are working on, breaking things down is often the best way to tackle a complex task. You might be surprised how much clarity this can bring to a tough problem. Even if you need to ask for help, having a list of things you've tried, and some data on the results is very much appreciated by those you ask. That way they know what you've tried and what to recommend.





Related content


Will the next version of Windows be a "Mini-Me" version of Vista? Who knows, and it's too early to tell, but apparently there's a mini-kernel version of Windows 7, the one after Vista, which fits into 25MB on disk. That's a touch lower than the 4GB that Vista takes up. Granted it's not a full […]


60 reads

An Hour in Time

Daylight Savings time switches a little later this year. In fact it's November 4th this year, after having been in October for all of my life. In case you don't remember which way we move the clocks, here's a saying: Spring forward, fall back.

5 (1)


199 reads

Software is Like Building a House

One of the really classic analogies in software is that it's like building a house. You have a foundation, multiple teams, lots of contractors that specialize in something, etc. And it's an analogy that's debated as to its relevance over and over. I won't go into the correctness of this analogy, but I wanted to comment on it.

2012-10-08 (first published: )

293 reads