To everyone following this train of thought, I think maybe the reality is that there are any number of ways of testing SQL, and I suspect that each of us has our favorite means and/or the means we are most competent to use. Some require additional software, some require additional knowledge and/or intuitive capabilities. I would submit that whatever the tool or level of abstraction, the intuitive ability of the tester is the most critical of all.

Although many if not most of you might not agree with me, my tool of choice is still SQL itself. I've tried other solutions myself, had worked with teams using various testing and debugging packages, and what I've seen is that the tools only go so far and are never as effective as plain old breaking the SQL into elements and making sure we understand exactly what each piece is doing.

One of my functions as an 'oldtimer' has been to mentor a number of folks new to the DBA world, and we don't depend on tools that the company may or may not decide to and continue to purchase/license or whatever. You need to understand SQL and be able to function whether tools are available of not. And that is how you find the most hidden of bugs or performance problems.