This blog will go over what you need to know for setting up your environment for remote debugging along with best practices and other things to consider when using the debugger in SSMS.
This 3 part series covers:
The debugger consists of 2 components. The server component is installed with the sqlservr.exe. The client component is installed as part of SSMS. When SSMS and the instance you want to debug are on the same system, there is nothing configure. You do however need to login to the instance as a member of the sysadmin role.
If you need to debug a remote instance, you need to enable the program and port exceptions using the Windows Firewall Control Panel application on both computers.
On the computer that is running the instance of the Database Engine, in Windows Firewall, specify the following information:
With the server instance taken care of, you now need to take care of SSMS on the client.
On the computer that is running SQL Server Management Studio, in Windows Firewall, specify the following information:
You are now ready to launch SSMS for remote debugging.
It is highly recommended that Transact-SQL code be debugged on a test server, not a production server, for the following reasons:
That’s it for part 2.
PingBack from http://blogs.msdn.com/billramo/archive/2009/04/11/transact-sql-debugger-for-sql-server-2008-part-1.aspx
Thank you for submitting this cool story - Trackback from DotNetShoutout
In part 3 of working with the debugger, I’ll talk about how to set breakpoints and the trick to setting
Bill Ramos, a SQL Server Product Manager, has written a three part series on how to use the SQL Server