locked
TSQL Debugger is not working after installing "VSTS - Database professionals" RRS feed

  • Question

  • Hi,

    After I have installed VSTS - Database professionals CTP5 I have found that TSQL debugger is not working any more.

    When I put breakpoint into the stored procedure and do "Step into Stored Procedure" the break point became disabled and the message is "The breakpoint will not currently be hit. Unable to bind SQL breakpoint at this time. Object containing the breakpoint not loaded."

    I'm absolutely sure that this was working normally before the installation of the CTP5.

    I'm guessing that something was done to the security settings by the installation package. I hope it is fixable.

    I'm running VS2005 and SQL Server 2005 Developer eddition and now SQL 2005 Express edition as second instance.

    CLR Stored procedures can be stepped through without any problems.

    Anyone has any suggestions how to fix my SQL Debugger?

     

    Maxim

    Thursday, October 12, 2006 8:25 PM

Answers

  • Maxim,

    I am sorry that SQL Debugging has stopped working for you.

    The RPC stuff should not be affecting you since you can still SQL CLR debug.

    Could you try deleting all the connections in your Server Explorer. There is a known issue that *dead* connections in Server Explorer can cause debugging to fail. (This issue will be fixed in VS SP1)

    If recreating your connections doesnt work, please contact me directly via email so we can sort this out.

    Rich  Cook   .A.T.   Microsoft   com

    Thanks

    Richard Cook

    Visual Studio Debugger Team.

    Thursday, October 19, 2006 9:25 PM

All replies

  • I'm surprised this is broken as we don't do anything to touch that area of the product.

     

    TSQL Debugging will only work off the Server Explorer and not within the DB Prop project. Are you setting the breakpoint in the editor which is launched from Server Explorer?

     

    mairead

    PM, TS Data

     

     

    Thursday, October 12, 2006 9:16 PM
  • Yes,

    I'm executing it from the server explorer and as i have mentioned it did work before.

    Just to make sure I have tried it on other's developer workstation where we do not have the tool installed and it is working properly.

    The debugger is not working on my workstation for the "old" database project neither for the "new" SQL Server 2005 project.

    Maxim

    Thursday, October 12, 2006 9:24 PM
  • Can you check that your user account is a sysadmin on the server. Also right mouse click on the connection in server explorer and ensure that Application debugging is enabled

     

    mairead

    Thursday, October 12, 2006 9:51 PM
  • Those were first things I have checked.

    Account I'm using to login on this workstation is a memeber of the "BUILTIN\Administrators" group and I have doublechecked that this group still in the sysadmin server role. The connection is enabled for "Application debugging" as well as "Allow SQL/CLR Debugging".

    And i want to point out again that debugging did work two weeks ago when I had no "VSTS - Database professionals" installed.

    I have carefully reviewd what other software packages I may have installed in this timeframe and there are no any.

    I was trying to search for related problem on internet and MSDN but almost all of the articles reffering SQL2000 problems and COM/DCOM security setting. In my case I have SQL 2005 and VS 2005

    Maxim

     

    Friday, October 13, 2006 3:07 PM
  • Sorry for the late responce, I have been looking into documentation to try and fix this

     

    Can you try the following

    How to use VS 2005 to debug TSQL for SQL Server 2005

     

    a) If you are using WinXP SP2, make sure Yukon Service is running under a domain account. If you are not using WinXP Sp2, please skip step b and c.

     

    b) If you are using WinXP SP2, run \windir\system32\gpedit.msc. In the Group Policy window, in the Tree tab, under Local Computer Policy, open the Computer Configuration. Open Administrative Templates. Open System. Open Remote Procedure Call Disable Restrictions for Unauthenticated RPC clients. In the Group Policy title bar, click the close box

     

    c) If you are using WinXP SP2, run regedit.exe, delete  'HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\RPC\RestrictRemoteClients', and reboot this computer.

     

    d) Open Whidbey to connect to a Yukon server with either

    1. a SQL account. also make sure the user account (NT login) on the client machine is the administrator account on the Yukon server.
    2. Or a NT domain user(with NT authentication mode). Make sure that domain account has permission to run the stored procure sp_enable_sql_debug on Yukon server

    e)  In server explorer, right click a TSQL stored procedure to select step into

     

    f)   If you are using WinXP SP2, you will see a warning dialog. Select the third option in firewall warning dialog. That allows every machine to go through firewall. Now you should be able to do TSQL debugging against Yukon

    Additionally

    TSQL (versions prior to SQL Server 2005)

    You must have permission to execute sp_sdidebug() on the SQL2000 or SQL7 database.

    On operating systems before Windows XP, SQL Server must not be running as Local System

     

    Thursday, October 19, 2006 7:31 PM
  • Am I the only one who shudders while reading steps b and c ?  Going back to the old days (pre SP2)? I seem to remember having to open up some other areas when SP1 of SQL 2005 came out (because of a crypto / certificates issue SSIS didn't run anymore). The network admins will love us.

    It also doesn't answer why it seems to have occured after the installation of VSTS4DBP. I still have a box without VSTS4CBP and will try to look into it tomorrow (will make an image first!!).

    Alle

    Thursday, October 19, 2006 8:04 PM
  • Thanks for the response, but it did not work.

    Both Visual Studio and SQL Server 2005 are installed om the same Windows XP SP2 workstation.

    I have validated the policy and it set to "Not configured" state and the entire key 'HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\RPC' does not exist in the registry it will appear only if i set policy value to somthing different than "Not configured". Just to make sure i have all options coverd i have followed your instructions and created local user gave it all required permissins and set it as acccount for SQLSERVER service. The final result is the same - I can't debug T-SQL.

    The debugging process is starting. But the debugger can't hit the break point (see message in the initial posting) if i will press F10(Step Over) or F11(Step Into) or F5(Continue) the execution of the stored procedure goes to the fery end without stopping anyware and in the output window i can see somthing like:

    Auto-attach to process '[3784] [SQL] maxim-t42p' on machine 'maxim-t42p' succeeded.

    The thread 'maxim-t42p [53]' (0x808) has exited with code 0 (0x0).

    The thread 'maxim-t42p [53]' (0x808) has exited with code 0 (0x0).

    The thread 'maxim-t42p [53]' (0x808) has exited with code 0 (0x0).

    The thread 'maxim-t42p [53]' (0x808) has exited with code 0 (0x0).

    Running [dbo].[StoredProcedure1] ( @parameter1 = 1 ).

    No rows affected.

    (0 row(s) returned)

    @RETURN_VALUE = 0

    Finished running [dbo].[StoredProcedure1].

    The thread 'maxim-t42p [53]' (0x808) has exited with code 0 (0x0).

    The program '[3784] [SQL] maxim-t42p: maxim-t42p' has exited with code 0 (0x0).

     

    By the way as I have mentioned in the initial question I can debug CLR procedures in the same instance of the server.

     

    Thank you

    Maxim

     

     

    Thursday, October 19, 2006 9:01 PM
  • We currently do not know why this is happening on your machine. From doing this install on my new clean box I am still able to TSQL debug

    mairead

    Thursday, October 19, 2006 9:06 PM
  • Ok I am getting one of the previous developers who worked on this to help out here

     

    mairead

    Thursday, October 19, 2006 9:09 PM
  • Maxim,

    I am sorry that SQL Debugging has stopped working for you.

    The RPC stuff should not be affecting you since you can still SQL CLR debug.

    Could you try deleting all the connections in your Server Explorer. There is a known issue that *dead* connections in Server Explorer can cause debugging to fail. (This issue will be fixed in VS SP1)

    If recreating your connections doesnt work, please contact me directly via email so we can sort this out.

    Rich  Cook   .A.T.   Microsoft   com

    Thanks

    Richard Cook

    Visual Studio Debugger Team.

    Thursday, October 19, 2006 9:25 PM
  • Richard,

    It did the trick!

    This is what i did:

    1. Remove ALL connection in server explorer.

    2. Close Visual Studio

    3. Open  Visual Studio

    4. Created Connection again

    5. Step into stored procedure - debugging works as expected.

    Thank you,

    Maxim.

     

     

    Friday, October 20, 2006 3:08 PM
  • Hi Maxim, Hi Richard,

    you guys were a bit faster. I also checked all of our boxes (some with and some without VSTS4DBP) and found one where T-SQL Debugging did not work.  It happens this box had not yet had any version of VSTS4DBP installed.

    Since this box gotten a newer Oracle Client recently, I decided to remove all the connections one at a time and reestablish them (with a restart of VS in between). Even though the Oracle Client has nothing to do with T-SQL Debugging, the old Oracle Connection was the cause of the error. After renewing that connection, the error was gone and I could T-SQL Debug again.

    It had nothing to do with VSTS4DBP.  It seems to be an internal problem with the VS server explorer that affects all connections even when only one should be affected.  Glad you cleared this up.

    HTH
    Alle

    Friday, October 20, 2006 4:11 PM
  • Alle,

    I agree - it does not have a direct connection with VSTS4DBP, but the installation process could be the cause of "broken connection". I do have another workstation without VSTS4DBP with the same problem and I was able to fix it the same way. As Richard indicated this will be addressed in SP1 for VS.

    Maxim

    Friday, October 20, 2006 4:38 PM
  • Super, thanks Rich and glad to hear that this is working again for both of you
    Friday, October 20, 2006 4:51 PM
  • I tried so manu different "complicated" things from all kind of blogs for this problem and this small little trick worked! I can now debug my stored procedure from my code. Thanks!
    Thursday, October 26, 2006 7:30 PM
  • This fixed the same issue for me as well.  Thanks a million. 
    Monday, November 13, 2006 7:55 PM
  • I have the same problem but not in VS2005.  Since installing CTP5 I have not been able to debug SQL in Query Analyzer and I have not been able to debug classic ASP pages in Visual Studio 2003. 

    Both of these worked prior to installing CTP5.  Now when I try to debug classic ASP, I do not even get the standard COM login box.  The debugger starts, just no breakpoints ever get hit.  That is the same in Query Analyzer.  The stored procedure will start but no breakpoints ever get hit.

    At least by finding this thread, I have a clue what happened.  I guess I will uninstall CTP5 and see if it fixes anything before installing CTP7.

    Please Help!

     

    Dale

    Monday, November 13, 2006 10:09 PM
  • Because I have been debugging my stored procedures in Query Analyzer, I had not tried debugging them in VSTS yet.  I still can't debug in Query Analyzer and can't debug classic ASP in VS2003 but I can debug stored procedures in VSTS.

    So, as much as I had hoped this thread was going to help with it, I am sure my problem lies elsewhere.  So, now that this is off-topic - I'd still appreciate any input if anyone knows what else I might try - I'll take this to the VS.Net debugging forum.

    Thanks,

    Dale

    Tuesday, November 14, 2006 8:54 PM
  • If you are trying to debug a SQL 2000 SP / Function with VS2005, check this out:

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=314468&SiteID=1

    it seems as if microsoft has disabled this functionality - you will have to upgrade to SQL2005

    to get it to work.

    Thursday, March 15, 2007 6:37 AM
  • I am experiencing all the same symptoms as Michtchenko, but the posted solution did not work for me.  Running VS 2K5 w/ Microsoft Visual Studio Team Edition for Database Professionals Version 2.0.50727.251

     

    I'm trying to debug a sp in a db on a named SQL Server 2005 instance.

     

    Any suggestions.

     

    Friday, April 6, 2007 12:55 AM