Home/ Questions/Q 3232130
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T17:07:31+00:00

I’ve recently put Windows 7 on my development PC, and I have Visual Studio

  • 0

I’ve recently put Windows 7 on my development PC, and I have Visual Studio 2008 Team System Development Edition, and SQL Server Management Studio 2008, and for some reason I can’t seem to step in to any SQL code for debugging in SSMS.

Before I formatted in favour of Windows 7, I was able to debug on the same two SQL servers I’m trying now with the same software, so I’m guessing it’s something to do with client configurations. Regardless, I tried all the steps I could find to enable SQL remote debugging but nothing has worked.

When I attempt to debug or step into the active query window, the debugger simply runs the code without stopping at the start or any breakpoints.

If I try use Visual Studio (running as Administrator) I get the following error:

T-SQL execution ended without
debugging. You may not have sufficient
permissions to debug.

Anyone got a clue what to do here?

EDIT

I’m still having this problem. I re-installed the latest SQL Server Management Studio from MSDN’s latest SQL Server 2008 download available, and patched it with SP1, but this same problem still happens. Other people in my office are able to debug code with the same version client, and same permissions (set using group permissions) so I’m at a loss as to what is causing this.

FINAL EDIT

Solved! The issue was simply a domain authentication issue. See my answer for a larger explanation.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Today, I finally solved this.

    I was writing an ASP.NET application that included the line:

    User.IsInRole("DOMAIN\\Administrators");

    And this was throwing the following exception:

    The trust relationship between this
    workstation and the primary domain
    failed

    I wasted a little time applying the KB976494 hotfix, which I soon discovered didn’t work. During my developer rage I looked in my local “Administrators” account and noticed it listed almost all members by their S-ID, so figured there may have been a domain problem.

    Then it came to me… I remembered I joined the domain with my personal (non-administrator) account, instead of using the domain administrator account.

    These were the ultimate steps to fix this issue:

    1. Leave your domain (and join an arbitrary workgroup, such as “WORK”)
    2. Reboot.
    3. Join your domain with your “DOMAIN\Administrator” account

    User.IsInRole() now worked, so out of curiosity I checked this problem, and it was also fixed.

    This is a great Friday so far!

    • 0