>>If the outcome is wrong, you only need to look at the SQL statement, not to weed through a long loop to see what is going on, on a record by record basis. You can capture a single SQL statement from the SQL profiler and analyze and debug it in SSMS. Just one single point of failure, not a 100 line long SCAN... ENDSCAN solution.
>>
>>I've been there, done that... writing a huge analysis program for different governmental bodies at several countries where the demanded statistical data was different each time. Moving the analysis from procedural fox code to SQL code made a HUGE, HUGE difference in maintainability. The code got much and much shorter, easier to read and if the values were wrong, you'd immediately know where to look. Not a 100 lines, but only a one or very few points in the program.
>
>One 100-column SQL statement is your worst nightmare. SQL will never, under no torture or hypnosis, tell you which column had the error. See the other thread, less than two weeks ago, about implicit cast of char to int, and the accompanying rant which I'd rather not repeat here.

In case SQL server returning an error, it indeed is inconvenient SQL server not giving you a clue. However, capturing the SQL statement through the profiler and debugging it in the SSMS is by far not as painful as weeding through a 100 line loop record by record in finding out the outcome is not as you expected.