How is remote debugging allowed on Microsoft SQL Management studio?
-
This is working with Sql Server version 2008 R2
Here are the other versions of software that might be helpful:
How is remote debugging allowed on Microsoft SQL Management studio?
This question might be misunderstood. I am not sitting at the computer where Microsoft SQL Managment studio resides and I am attempting to debug a remote database. That is not the issue I am having at all. Instead, I have remoted into a client's server by their request and also I am trying to debug an issue they are having. You see, this is how things are evolving in our world. More and more there are situations where a developer is working from home and has to remote into a client's system do get some work done.
When I open up their studio software on their side, if I try to debug or execute a command, I get this error message:
I want to be able to instruct them, on their side, what they need to do to make this problem go away. Please advise.
-
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
-
Thank you for your outstanding post. I think sp_sqltrace looks very promising and I would like to see actual demonstrations and examples of it working but the documentation looks good.
I want to take a multi-pronged attack on this problem.
I was looking around at the list of databases on the server today as I was remoting in. I noticed there were some databases that were named with similar names apart from just one difference. The differences were that the names ere concatenated with "DEV" and "DEV2". In other words, for example, sometimes if there was a database called "CUSTOMERS" there would also be another database immediately under that called "CUSTOMERSDEV" and possibly there would be a "CUSTOMERSDEV2".
This makes me think that there might be certain settings that a development database is set up with verses a production database, obviously, and that the conditioning that separates production from development is not dependent on the server.
So I have this question. How does one configure a SQL Server Database for development, testing and debugging?
-
Well first things first, you really need to be telling the client that they need to get off SQL 2008 and like 2 years ago, so you really need to be pushing them for an upgrade and sharpish.
2008 is now end of extended (CVE patches) only and 2012/2014/2016 are only in extended support, so depending if your client has to adhere to certain regulations they are at serious breach of contract and should be running 2017 or 2019 with a push to be on 2019 as best they can.
Debugging has been removed from SSMS for a number of versions now, so I would highly advise against using it on older servers if Microsoft have removed it, there must be a serious reason right?
Debugging is an art form and to do it right you need to explore what the issue is first. You have not eluded to what it is you need to debug or what the issues are.
As for how do you configure it for dev/test/debug, well they should really all be separate servers, there should be environmental separation wherever possible. After that it is up to the application to work out if a database is dev/test/debug/prod based off of the connection strings and any configuration tables within the database to make it a dev/test/debug/prod version of the database, that is entirely application dependent and nothing that can be shared on a forum who have no information about the app, its background etc, you need to get that "domain knowledge" from your client.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply