|
|
|
|
|
SQL-Programmer IX SP2 with TSQL Debugger 1 2 3 4 5 6 7 8 9 10 11 12 Breakpoints can be extremely useful in tracking down problems. Some of the systems I've worked on have extremely complex and convoluted procedures. One of the worst had over 180 stored procedures wired together that called each other all executing within multiple levels of cursor loops. Needless to say, there was always something that needed to be adjusted. Many times they could pin it down to somewhere in the process, but not specifically where. At this point, they would put in a lot of print statements, log all kinds of things, etc. By using breakpoints, you can significantly streamline this process. Simply open the procedure that calls everything and the procedure where you think the problem starts. Set a breakpoint at the beginning of that procedure. Then start debugging and run it to the breakpoint. You now have the full call stack of how it made it to that point and are ready to start walking through that piece to isolate the problems. You can also use this approach to determine how you got to a particular procedure when you can't unravel things.
Of course a debugger wouldn't be complete without the ability to change values of variables.
SQL-Programmer IX SP2 with TSQL Debugger 1 2 3 4 5 6 7 8 9 10 11 12 |
All content on this site, except where noted, represents an original work of Michael R. Hotek and is protected by applicable copyright laws. The SQL Server FAQ is the sole work of Neil Pike. No page, portion of a page, or download may be used for commercial purposes in whole or in part without the express, written permission of the applicable author.
