Post reply

Transact-SQL Debugger

  • May 27, 2003 at 3:03 pm

    #159612

    I used to be able to step through the SP's, but now the debugger runs the sp without the ability to step or restart.

    Any ideas?

    Did this go away with SP3 for S2K?

    Thanks

  • May 28, 2003 at 7:18 am

    #458826

    Does anyone even use the debugger ?

  • May 28, 2003 at 9:17 am

    #458854

    I use it on occassion.

    I have seen issues where the security accounts that run SQL server change or the rights for those accounts change.

    I just checked one of my SQL 2000, SP3 servers and I can still debug on it.

    Steve Jones

    sjones@sqlservercentral.com

    http://www.sqlservercentral.com/columnists/sjones

    http://www.dkranch.net

  • May 28, 2003 at 9:48 am

    #458865

    I have similar behavior when I run the debugger from a remote machine. When I logon directly to the machine using terminal services or dameware and then open query analyzer the debugger works. If you remotely login try a direct login and see if that does the trick.

    -Mark

  • May 28, 2003 at 9:49 am

    #458866

    Debugging Functionality Changes Introduced in SP3

    The functionality for debugging stored procedures with Microsoft Visual Studio® 6.0 and older or with SQL Server Query Analyzer prior to SP3 is turned off by default. Application debugging (stopping at a SQL Server Transact-SQL breakpoint while debugging a client application) is also turned off by default. To enable debugging functionality, run sp_sdidebug, passing the parameter legacy_on. To disable debugging, pass legacy_off to this procedure.

    Note Running the sp_sdidebug stored procedure on production servers is not recommended.

    For more information, see Microsoft Knowledge Base article 328151. This article is available at the Microsoft Product Support Services Knowledge Base.

  • May 28, 2003 at 12:20 pm

    #458889

    Thanks for the reference to Article 328151. I had not applied SP3 to workstation that only has client tools.

    I did that, rebooted, and everything is well.

    Thanks again.

  • May 29, 2003 at 2:27 am

    #458958

    Just a personal note to agree with Allen, running the debugger against a production server is not advisable, and I tend to avoid the debugger at all costs.

    Personally I put a backdoor in the applications which can open and dump information out on request, this way I can see variables, SQL statements, results and errors that the user doesn't see. I will even do this on the fly if necessary.

    I will also run the procedure with the same information from the Quesry analyser, first by calling the sp with the same parameters, and then copying the code of the sp into the query analyser and manually setting up declares for the variables. I know it seems a little long winded, but it is surprisingly quick. A fre print statements and a SET NOCOUNT OFF and I can quickly find where information and flow control has gone awry and narrow it down and cure it.

    Worth bearing in mind.


    ---------------------------------------
    It is by caffeine alone I set my mind in motion.
    It is by the Beans of Java that thoughts acquire speed,
    the hands acquire shaking, the shaking becomes a warning.
    It is by caffeine alone I set my mind in motion.

  • May 29, 2003 at 8:10 am

    #459012

    The debugger behavior has changed in SP3, so that owners of objects can only debug objects they own. This is true even with SP3 on server and workstation. Prior to SP3 developers where able to debug objects which they did not own provided they permission to master..sp_sdidebug. The workaround for this is to create objects under their own user account. KB article 328173 describes this change.

  • May 29, 2003 at 7:02 pm

    #459136

    I have 1 developer that uses this tool. First time I have ever EVEN seen it. Personally I dont like the tool.

    We had problems with it after converting to SP3. Solution was to convert ALL machines to SP3, follow the directions for modifying SQL server agent to be run by non-sa's. And ensure that everyone is on the same domain. It then started working.

    I like the old way of build test this part build some more etc...

    Good Luck

    AJ Ahrens

    SQL DBA

    Revenue Assurance Management - AT&T



    Good Hunting!

    AJ Ahrens


    webmaster@kritter.net

  • May 30, 2003 at 7:22 am

    #459175

    Thanks for sharing the article. After reading it, I do like the new SP3 security implementation.

    quote:

    The debugger behavior has changed in SP3, so that owners of objects can only debug objects they own. This is true even with SP3 on server and workstation. Prior to SP3 developers where able to debug objects which they did not own provided they permission to master..sp_sdidebug. The workaround for this is to create objects under their own user account. KB article 328173 describes this change.

  • May 5, 2004 at 6:29 am

    #505287

    thank god you have dicussed this problem . i got the solution


    Rohit

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply