When trying to debug a T-SQL query within Azure SQL Managed Instance database from Visual Studio, I get an error:
Failed to start debugger and exception was generated: Data is null. This method or property cannot be called on null values
Followed by this:
Unable to start program MSSQL Operation not supported Unknown error 0x80004005
Debugging a T-SQL query from within Visual Studio 2019 current version 16.11.11 yields the following errors:
Failed to start debugger and exception was generated: Data is null. This method or property cannot be called on null values
Unable to start program MSSQL Operation not supported Unknown error 0x80004005
Azure SQL Managed Instances cannot be debugged using the debug method of SSMS or via Visual studio. Answer by the MS support team : " As discussed Azure SQL Managed Instance does not support debugging as SQL Server engine DDL’s which is required by the debugger are not accessible in PaaS environment."
On all Azure SQL PaaS database options (DTU model, vCore model, Serverless, Managed Instance, Hyperscale) and Synapse you will have that constraint. Even tools like SQL Server Management Tools (SSMS) that once had a Debugger integrated it no longer has it, and honestly it was never useful when I had to use it.
Azure Data Studio has a Profiler Extension that help a little bit to determine the sequence of instructions that were executed to produce a result set but won't help you to watch the values of variables.
If all this is painful for you maybe your organization should consider choose a SQL Server VM (IaaS) instead of PaaS.
You can also export Azure SQL Databases to a local developer environment and do debugging locally.
Finally, if you need to debug on Production use PRINT or SELECT statements of T-SQL to watch the values of variables or display intermediate result sets. You can also save intermediate results or outputs into a temporary table or log table.
Related
I need to set OPTIMIZE_FOR_SEQUENTIAL_KEY = ON for several of my PKs on tables in Azure SQL Databases.
Running the code in SSMS against Azure SQL works perfectly, as expected. But, when I add the text for this index option into my database project in VS 2019 (16.6.2), I get the following error:
SQL71627: The element Primary Key: [dbo].[PK_UserActions] has property DoOptimizeForSequentialKey set to a value that is not supported in Microsoft Azure SQL Database v12.
This VS error is invalid since this option is valid/allowed/supported in Azure SQL (according to official documentation and actual functional validation), and it works perfectly in all my instances (Microsoft SQL Azure (RTM) - 12.0.2000.8). But, I cannot find a way to suppress this bogus error so I can build and publish my DACPACs.
An old SO answer said to target the project to "SQL Server 2019 and Azure SQL", but this no longer exists. The only other target platform beyond "Microsoft Azure SQL Database" is "SQL Server 2019 and Azure SQL Database Managed Instance". When selecting the latter target platform, the VS project builds properly.
But, I am not targeting a Managed Instance, so I am concerned about having to use a bogus target platform to get around an obvious VS2019 compiler error.
Am I justified in being concerned here, or should I just target the wrong platform which builds and hope for the best, or is there some non-kludge way to make this work properly? I've tried all suppression techniques to ignore the error on build, but nothing works.
Thanks!
I have written a CLR stored procedure (.NET Framework 4.5 and IDE VS 2019) and trying to debug the CLR stored procedure before deploying it to SQL Server 2016. However, I am unable to locate the debug option for CLR DB object.
I did try steps provided on Microsoft document but unable to find [Test Scripts] folder in Solution Explorer. I am using Visual Studio 2019.
https://learn.microsoft.com/en-us/sql/relational-databases/clr-integration/debugging-clr-database-objects?view=sql-server-2016
What exactly do you mean by:
debug the CLR stored procedure without deploying it on SQL server
? The code only runs in SQL Server. It needs to exist within SQL Server in order to be callable as the environment that calls it is SQL Server. Visual Studio comes with SQL Server Express LocalDB so that you can easily test stuff like this on your local dev box without having to deploy it anywhere outside of your personal dev environment. When you create a database project, the debug connection string (i.e. where it deploys to when publishing to test, whether you start debugging or not) should be preconfigured for your local instance of LocalDB.
Please try the steps I outlined in my answer to "How to debug a CLR Stored procedure in VS 2013". That was tested on VS 2015, and I expect the behavior to be the same in VS 2019. Either way, that answer contains some required steps that are missing from the MS documentation.
https://msdn.microsoft.com/en-us/library/hh272701(v=vs.103).aspx
From the above link, it seems it is possible to debug a stored procedure in SSMS.
I am accessing a SQL Server instance using SQL Server authentication with admin privileges. I want to debug a stored procedure in SSMS, but I don't get that option.
Somebody told me that it works only with Windows authentication (while connecting to the database). I don't know to what extent this is true.
What are the prerequisites for allowing to debug a stored procedure? Because in deployment, stored procedure might have 50k lines and it would be hard to debug by print selective statement to get the clue and all (workaround).
Following are true in my case:
SSMS is professional edition.
SQL Server user for accessing is admin user
(IMHO, there needs to be a way to debug a stored procedure with SQL Server authentication mode too).
So, I would really appreciate, If someone can take me through that process
Yes, you can debug... I'm doing it right now with SQL Server 2016 and SSMS 17.6.
I'm using Windows Authentication.
Check the following printscreen.
In my case problem was firewall. In mostly companies Window's firewall is disabled and some other tools such as symtanec or third party application firewall are used.
It is tough for IT security to turn on or set those extra filter for SQL Server.
So, I had to screw my head everyday with same crap
This is not available in SSMS. You need SQL Server Data Tools (SSDT) to use the debug in stored procedure. You can download it here.
You can connect as Windows Authentication or SQL Authentication. Just make sure you have proper read/write access to view and execute the stored proc in Development Environment. Avoid using this tool in Prod.
I'm installing a program that often throws an exception due to either a wrong parameter in an INSERT statement or permission problems on the database. I do have full administrative rights on the SQL Server and it would be nice to log failed INSERTs etc. and the reason why they failed. The stack trace from the C# code shows only that a parameter is too long, but not which one of them and what the value was. Therefore it would be the easiest solution to solve SQL problems via SQL Server Studio Management rather than making code changes to a release of a product.
The values of parameters can be viewed in SQL Server Profiler (Sql Server Management Studio: Tools -> SQL Server Profiler). It can be configured to save trace to db (if you can't reproduce an issue on test environment), and catch only certain calls (for example you can specify the name of your stored procedure).
Here is screen shot of profiler with stored procedures calls with all parameters:
Is there any way to debug a stored procedure on SQL Server 2008?
I have access to use SQL Server Management Studio 2008 and Visual Studio 2008 (not sure whether either provides this functionality).
Generally I use the SQL profiler to find the parameters passed to the stored proc, however would like to be able to step through the procedure to see where it is failing.
Is this possible?
What is the best way? (in terms of quickly finding location of bugs)
Well the answer was sitting right in front of me the whole time.
In SQL Server Management Studio 2008 there is a Debug button in the toolbar. Set a break point in a query window to step through.
I dismissed this functionality at the beginning because I didn't think of stepping INTO the stored procedure, which you can do with ease.
SSMS basically does what FinnNK mentioned with the MSDN walkthrough but automatically.
So easy! Thanks for your help FinnNK.
Edit:
I should add a step in there to find the stored procedure call with parameters I used SQL Profiler on my database.
Yes you can (provided you have at least the professional version of visual studio), although it requires a little setting up once you've done this it's not much different from debugging code. MSDN has a basic walkthrough.
Yes, although it can be tricky to get debugging working, especially if trying to debug SQL on a remote SQL server from your own development machine.
In the first instance I'd recommend getting this working by debugging directly on the server first, if possible.
Log to the SQL server using an account that has sysadmin rights, or ask your DBA to to do this.
Then, for your own Windows account, create a 'login' in SQL Server, if it isn't already there:
Right-click the account > properties - ensure that the login is a member of the 'sysadmin' role:
(also ensure that the account is 'owner' of any databases that you want to debug scripts (e.g. stored procs) for:
Then, login directly onto the SQL server using your Windows account.
Login to SQL server using Windows Authentication (using the account you've just used to log into the server)
Now 'Debug' the query in SQL management studio, setting breakpoints as necessary. You can step into stored procs using F11:
Here's a useful guide to debugging:
http://blogs.msdn.com/b/billramo/archive/2009/04/11/transact-sql-debugger-for-sql-server-2008-part-1.aspx
If you need to remotely debug, then once you've got this part working, you can try setting up remote debugging:
http://blogs.msdn.com/b/billramo/archive/2009/04/11/transact-sql-debugger-for-sql-server-2008-part-2.aspx
One requirement for remote debugging is that the windows account used to run SSMS be part of the sysadmin role. See this MSDN link: http://msdn.microsoft.com/en-us/library/cc646024%28v=sql.105%29.aspx
MSDN has provided easy way to debug the stored procedure. Please check this link-
How to: Debug Stored Procedures