Friday, February 24, 2012

Debugging or a parody on it?

Hi, I am new here.

I tried to debug stored procedures in the Visual Studio and you know… it was a real shock. Like going in time 10 or 20 years back.

The stored procedures I deal with contain a lot of @.tab and #tab, but it appears that I can not evaluate the values of these objects! The only type of object I can evaluate is a variable. But SQL is designed for the table data, right? So the most important type of data is not accessible!

How can I understand, what records have been affected by Update or inserted by Insert? Using prints or debug selects? Is it an era of FORTRAN or ALGOL?

To make it worse, to enter a debugger, I need to provide values of all parameters. It might be simple for the outermost procedure, but for inner stored procs, and where some parameters are some short-living identity values of some records, created in a transaction, it is very difficult to prepare all conditions to make a correct run.

So my question is, may be I had overlooked something? Is it a real debugger or just a joke from Microsoft? Sorry, but I am really angry after wasting a lot of time last week on it.

If you want to trace changes on the record level it might be better to enable auditing in SQL Server and examine the log files with Profiler. Here is one article about enabling auditing in SQL 2000:

http://www.microsoft.com/technet/security/prodtech/sqlserver/sql2kaud.mspx

|||

Thank you. But agree with me, it is far from simplicity of the debugging process we have with C# code.

Ok, I'll google if there any 3rd party tools.

No comments:

Post a Comment