July 20, 2004 at 12:54 pm
Until I found this discussion ( http://www.sqlservercentral.com/forums/shwmessage.aspx?forumid=29&messageid=121410&p=1 ), I was not aware that Query Analyzer had a debugger—I had read a while back that you needed Visual Studio instead. However, it seems to work fine on small stored procedures at our site, as long as SP3 is installed. On the other hand, large stored procedures appear to make the debugger lose track of which line is actually executing when the debugger advances past the first row of syscomments to the second row in syscomments--i.e., after the 4000 bytes of the stored procedure, the debugger displays an incorrect line (a comment in my case) as the next executable line.
Question 1: Has anyone seen the same problem?
Google turned up some warnings about granting EXECUTE on sp_sdidebug, but I never found any reason(s) why.
Question 2: Can anyone tell me the risk, if any, of granting EXECUTE on sp_sdidebug to public (or some more restrictive group) so that non-privileged Developers can use the debugger in Query Analyzer?
Thanks in advance,
Jon
July 23, 2004 at 8:00 am
This was removed by the editor as SPAM
September 13, 2004 at 8:25 am
I haven't had this particular problem, but there are some alternatives to using the debugger.
1) Pull the stored procedure contents out and paste them into Query Analyzer; and step thru the code until you've figured where the problem is. (Note, you may have to modify so that it doesn't affect production data, inserting/updating a smaller test table rather than the production data, etc.)
2) Use an alternate debugging tool such as the one available from CAST Software in their SQL Builder tool. This tool can give you a flow chart of the stored procedure as well as debug the stored procedure. Sometimes it's the flow control of the stored procedure that's wrong, not the code that modifies the data.
Thanks,
Jeff M. Belina
Sr. Database Developer/DBA
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply