December 22, 2018 at 11:29 am
Comments posted to this topic are about the item Evolving Our Tools
January 3, 2019 at 2:47 pm
Are there any SSMS alternatives or plugins that support T-SQL debugging, especially against a Managed Instance? I'm very disappointed the Microsoft is dropping this entirely from SSMS19 instead of updating it.
January 8, 2019 at 3:38 pm
I haven't seen anything really geared to MI. They're new, lightly used, and expensive. A pain to provision, so even for us as vendors (Redgate), it's a PIA working with them to test software.
Almost no one used debugging. If you did and it worked well, good for you, but it's a lot of code, and the effort to maintain it doesn't justify the return. I'm glad they removed it as the buttons constantly got in my way, and it wasn't the most stable system.
January 8, 2019 at 4:20 pm
Yes, I used it extensively; it wasn't perfect, but it helped quite a bit. We just migrated a large system with somewhere around 2K SPs and functions from MySQL to SQL Server. The Migration Assistant was helpful, but also has some major bugs, and the debugger was quote helpful in figuring out where things had gone wrong.
Customizing SSMS to move or hide buttons you don't use isn't difficult, so "the buttons got in the way" isn't all that convincing an argument.
As for MI costs, I wasn't involved in the decision to use MIs over Azure SQL for the new system, but it seems to be working well so far. . No difficulties in setting up proc and test systems; we kept dev in an on-prem VM specifically to be able to use the debugger.
January 10, 2019 at 10:09 am
Just remember your frame of reference or way of working isn't everyones. I hit a lot of new SSMS installs, so customizing all of them isn't practical. Usually run SSMS over RDP on another box.
The debugger just wasn't used often. The telemetry from MS shows that it's very rarely used by most developers, so they decided to stop supporting it.
January 10, 2019 at 5:33 pm
I'm aware that every one's situation is different -- your way isn't universal, either. As it happens, most days, I'm using RDP on an iMac to connect to a Surface Pro where I'm running SSMS; I'm working with a combination of Azure MI, Azure SQL, SQL Server on an Azure VM, SQL Server on an on-prem VM, and SQL Server on-prem halfway across the country, because corporate politics are weird and complicated, and different people made different decisions at different times, based on different factors. Depending on what I'm doing, I may then have one or more additional RDP sessions from the Surface to servers elsewhere, and might or might not be running SSMS on a remote server as well.
But none of that is relevant to the issues at hand. While I am personally disappointed that MS is dropping a tool I found useful, and which others might have used more if it had been improved instead of being dropped, I'm not out campaigning for them to bring it back. I simply asked if anyone knew of other tools in that niche. A simple "no", or no answer at all, would have been sufficient, but you seem to be trying to convince me I'm wrong to find it useful, which seems bizarre to me. You don't use it, fine; what purpose does telling me serve?
January 10, 2019 at 8:36 pm
Apologies, not trying to convince you you're wrong. My comment about my situation was an aside, and my response was about your noting it's easy to reconfigure SSMS. It is if it's my machine, not otherwise.
To your question. I know of no third party debugger for T-SQL. AFAIK, there isn't an API to connect to the SQL Server and stop code from executing. You can certainly use Windbg for the sqlsrvr.exe process, but that's not what would help you with T-SQL in most cases.
You are welcome to try and get people interested and vote at: https://feedback.azure.com/forums/908035-sql-server/suggestions/35881492-put-debugger-back-into-ssms-18
I doubt you'll change their minds, as it seems very few people use this, but you can try. Welcome to ask others for votes as well.
January 10, 2019 at 8:38 pm
Actually one with more votes: https://feedback.azure.com/forums/908035-sql-server/suggestions/35691865-dont-remove-debugging-from-ssms-18-0
January 10, 2019 at 9:20 pm
Thanks. It really is useful to me for tracking down errors in complex nested SPs with multiple dynamic SQL statements, etc. (Yes, some of them could be refactored to be simpler, but there's only one of me, and a couple thousand SPs / functions....)
January 10, 2019 at 9:22 pm
Although, really, I find that when something is a niche interest, a third-party tool is often a better option. They can charge enough to support the development effort necessary, while MS is giving away SSMS, and is going to have different priorities.
January 11, 2019 at 8:29 am
From our perspective, at Redgate, we've talked about this. There is a lot of engineering to building a debugger and it takes quite a bit of support. SSMS is a mess of an architecture and it doesn't easily allow add-ins, which is a shame. We found it's not commercially viable due to the overhead for us.
At a smaller company, maybe you could make it work, but it's hard to charge more since most people won't want to pay high prices. We've abandoned our memory profiler as not enough people want to buy it. Most just spend more on people and hardware and think that's a good trade.
January 11, 2019 at 1:15 pm
Heh... you learn all those wonderful tools and begin to rely on them. Then, something happens and you end up at a new company and you're dead because 1) they don't have any of those tools and/or 2) (right or wrong) their security requirements don't allow those tools (been there and done that).
While you learn to use all those shiney new toys, don't forget the original stuff, which may be the only show in town at your next gig. Just sayin'...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2019 at 2:17 pm
Jeff Moden - Friday, January 11, 2019 1:14 PMHeh... you learn all those wonderful tools and begin to rely on them. Then, something happens and you end up at a new company and you're dead because 1) they don't have any of those tools and/or 2) (right or wrong) their security requirements don't allow those tools (been there and done that).While you learn to use all those shiney new toys, don't forget the original stuff, which may be the only show in town at your next gig. Just sayin'...
At my current position, I asked for RedGate SQL Prompt when I was a contractor. They decided it was such a good idea that they gave it to all of the employees who did SQL development, but not the contractors. When I became an employee, I asked for it to be installed, but my request was denied. :crazy:
Drew
J. Drew Allen
Business Intelligence Analyst
Philadelphia, PA
January 11, 2019 at 9:01 pm
If the past is anything to go by, there's at least a 50% chance I'll be using completely different tools in my next job anyway. This company was using MySQL when I was hired; migrated to SQL Server last year. Company before that was PostgreSQL. Before that, was MySQL when I was hired, migrated to PostgreSQL. Before that, MySQL; before that SQL Server. Mostly Linux, sometimes Windows. A lot of Perl, a lot of bash, a bit of JS, Python, TCL, and more. C++ a long time ago. It's been an interesting 20 years!
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply