greg

My feedback

  1. 838 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    under review  ·  307 comments  ·  SQL Server  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    greg commented  · 

    I cant upgrade to SSMS 18 because it does not support server debugging of deployed server code. We have a massive code base across hundreds of databases that simply cant be properly debugged in the visual studio tools. The SSMS 17 debugger is clunky, but its invaluable at understanding how hundreds of thousands of lines of code interact in specific environments.

    If your developing simple little UI applications that need to store data, sure you can debug this in visual studio, but if your doing massive data warehousing, data matching and real data processing work, you need a debugger that can operate on whats released, not whats in a specific branch of source control .... which may or may not be in sync with what is deployed to different environments ... which may or may not be possible for my dev machine to connect too.

    There is such a large gaping hole from the product management team on this. Some rational explanation would be a good starting point. A technical vision to cover this requirement would be even better ... rather than just drop support of something many of us have found invaluable and use every day.

    There is a similar request in this thread:
    https://feedback.azure.com/forums/908035-sql-server/suggestions/38139325-put-debugger-back-into-ssms-18

    And another set of feedback for the same feature here:
    https://feedback.azure.com/forums/908035-sql-server/suggestions/35691865-ssms-dont-remove-debugging-from-ssms

    Not sure if all three of these threads can be merged to show the level of support from the community on this issue.

    greg supported this idea  · 
    An error occurred while saving the comment
    greg commented  · 
    An error occurred while saving the comment
    greg commented  · 
    An error occurred while saving the comment
    greg commented  · 

    Why cant we get to this old thread with so many votes: https://feedback.azure.com/forums/908035-sql-server/suggestions/35881492-put-debugger-back-into-ssms-18

    This thread is also asking for the same thing:
    https://feedback.azure.com/forums/908035-sql-server/suggestions/35691865-dont-remove-debugging-from-ssms-18-0?page=2&per_page=20

    In the v18 release notes (https://cloudblogs.microsoft.com/sqlserver/2019/04/24/sql-server-management-studio-ssms-18-0-released-for-general-availability/#), there is a mention of this feature disappearing and some comments that point to SSDT as a solution. From my limited exposure to SSDT debugging, it looks designed for nice tidy clean projects where everything is all checked in and perfectly accounted for. This is wonderful world to live in and a great place to use SSDT. But, in many places SSDT cant represent all of the code. The old debugger just runs on the server and doesnt care anything about how messed up your code/release process is ... it just runs and lets you figure out whats going on.

    An error occurred while saving the comment
    greg commented  · 

    Please bring the debugger back into SSMS. Its old and rickety, but invaluable in digging into complex logic.

Feedback and Knowledge Base