Debugging or a parody on it?

[evilDBA]

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.

 

[Crowley16]

I never use the sql debugger...

--------------------
Procrastinate Now!

 

[evilDBA]

So, only debug selects?
No other way?

 

[LNBruno]

In SQL Server 2005, you can make use of the OUTPUT clause. It is similar to triggers in that it is based on the usage of Inserted and Deleted tables:

--returns modified records in their original state:
          UPDATE dbo.MyTable
             SET myColumn = '111'
OUTPUT DELETED.*
           WHERE myColumn = '1'

< M!ke >
[small]"Oops" is never a good thing.[/small]

 

[mrdenny]

I agree with Crowley16. I never use the SQL debugger.

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com

 

[evilDBA]

Hi, thank you all.
Look what I had googled, images look promising, I will try it.

http://www.sqlsolutions.com/products/sql-ultimate-debugger/screenshots.html

 

[TysonLPrice]

I do use the debugger although not from the application. One nice thing about it is it steps through the triggers. There could be trigger activity you aren't aware of. Especially if you are new to the environment and don't know it like the programmers that developed it.

As far a debugging from the application I usually take what it is passing to SQL and cut and paste it into query analyzer to debug it.

 

[ca8msm]

I also use SQL Profiler quite a lot to see exactly what is being executed.


------------------------------------------------------------

Mark,
[URL unfurl="true"]http://aspnetlibrary.com[/url]
[URL unfurl="true"]http://mdssolutions.co.uk[/url] - Delivering professional ASP.NET solutions

 

[evilDBA]

>I also use SQL Profiler quite a lot to see exactly what is being executed.

It is much more difficult for nested procedures.

BTW the utility I found really works.