Can conditional breakpoints be set while debugging in SSMS? - sql-server-2008

I've just begun using breakpoints to debug a T-SQL stored procedure in Management Studio (SQL Server 2008). I notice that the breakpoints window has a condition column:
But I can't find any way to actually specify a condition on a breakpoint, not via the Debug menu, not via a context menu on the breakpoint or within the breakpoint window, etc.
Is there a way to use conditional breakpoints in SSMS, or does that column exist for some future version?

No, they can't. From this site, you can see some of the other limitations also.
Here's the relevant quote:
The T-SQL debugger does not support the Microsoft Visual Studio features of setting breakpoint conditions or hit counts.

I have found a workaround:
in case my condition is #IterationNR = 18 I have stated
IF #IterationNR = 18
SET #IterationNR = #IterationNR
and set breakpoint to line with SET command...

Another alternative would be to create a C# or VB .NET application that uses ADO .NET to execute the SQL query that you were executing on SQL Server Management Studio, and set the conditional or hit-count breakpoint within Visual Studio on the SqlCommand object.

Related

sql debugging in vs2010 confusion

After much work i've configured my machine (win 7 x64, VS2010, SQL 2008 R2) to be able to debug stored procedures locally from within visual studio. My question is about how the debugging context is supposed to switch as you debug.
an example:
when debugging and I call another vb class the debugger follows and jumps to that class for me to step through. when I hit a sql call is there a way to tell the debugger to follow it there too?
currently the only way I can debug a stored procedure is to right click it and choose "step into" and provide values. Those values I have to determine by running my app, making edits, and writing down my param values I was going to pass into the stored procedure. Then going back and stepping into the stored procedure with those values allows me to track and use intellesense to debug the sql stuff.
What i'm looking for though is to have the debugger do the switching for me. So I don't have to do as much work to step through stored procedures. When I run my application and open one of my stored procedures to view the breakpoint symbols are not loaded but it does say it has auto-attached to the sql process and everything.
Wasn't sure if this was how sql debugging was supposed to go or if I did something incorrectly. Figured someone here might know what was going on. Thanks for looking!
my target framework was dot net 4 client profile. When I swapped to full dot net 4 framework and rebuilt everything started working like I thought it should. My only guess is that some of the sql-clr debugging stuff is trimmed out of the client profile?
Try the following.
The standard workflow to debug a CLR SQL assembly is the following…
Right-Click the project and select ‘Deploy’
Debug | Attach to Process…
Select the Process ‘sqlservr.exe’ and make sure it is the one with a Type of ‘T-SQL, Managed, x86 or x64’
Press the Attach Button

SQL Server 2008 Debugger Attach?

I have seen a few posts here about using the native MSSQL 2008 functionality to debug and step through TSQL.
In a Visual Studio 2010 .NET C# console app, I use simple ADO.NET to send some params to a stored proc. I can run it in the debugger and see what happens in the .NET code up until the point where the SqlCommand is executed. How can I get the debugger (or any debugger) to fire on the MSSQL side so I can follow data from the C# all the way to/though the DB?
Thanks.
If you want to capture what is sent cross the wire, use SQL Profiler.
Using SQL Server Profiler
If you are having problems stepping into a stored procedure from Visual Studio:
How to: Enable Transact-SQL Debugging
Walkthrough: Debug a Transact-SQL Stored Procedure
[Please note: your mileage may vary; I've known systems where this just wouldn't work. So much so, I never try to step into TSQL any more...]

How and where in VS2008 I can see my Linq commands being translate into Transact-SQL statements?

Linq commands are translated into transact-sql statements. I've VS2008 professional. How and where can I see how this majic happens? (by debugging?)
EDIT
Let's say I have this
var allProducts = db.Products;
I guess this will be translate by
SELECT * FROM Products
Where can I look at to see that? For instance, when I debug my code, I can see on the bottom are changing value each time I press f10. Is there something like that in vs2008 for linq command?
You can use the Log property on the DataContext object.
You can configure VS to step into .NET source code:
Configuring Visual Studio to Debug .NET Framework Source Code

SSRS and MDX causes VStudio to crash

I am trying to generate a report using reporting services in visual studio 2005. the data source is in MDX DB and was created successfuly. When I save the query in the query builder window it closes and displays an alert : "the query cannot be read from the query window, please check for syntax errors"
and then VS crushes!
the query has no parameters and works on management studio without any problems.
I have installed all of my win updates, but sql server sp3 (that had a problem)
I also have service pack 2 for my framework
any idea what is going on?
try pasting from VS into notepad (or SSMS) and then copy from notepad (or SSMS) back into VS to make sure that there are not any "strange" characters (like smart quotes). It's vaugely possibly that SSMS is stripping these out when you paste into it.
Otherwise it may be an issue with your failed SP3 install.

Does sql profiler show you the paramater values that were passed in?

I'm using this 3rd party sql tracing application because I have sql server express 2008 installed (just a trial version).
It only shows the sql passed into the server, with the parameters like #p1 and not that actual value of the parameter, which to me is not all that usefull.
Does the built in sql profiler show you the actual values the .net web app is passing in like '2342' or a = 200 ?
yes, it shows the query with the parameters already substituted. When I debug, I usually just copy the SQL from the profiler and paste it into Management Studio and run it.
It can. When you define a profile template, you can specify which sql "things" you want to see and which columns (information) you want to see for each "thing". So if you aren't seeing the parameters, you may have to modify the profile template you are using.