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:
Related
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.
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 know there are other questions here concerning this same issue, but I none of the suggestions on any of the questions are helping.
I'm trying to debug a stored procedure, to step into its code from a VB.Net application.
I can step into the stored procedure using Server Explorer in VS 2010. I can't, however, go from code in my .Net app into the stored procedure. I have breakpoints both in my .net code, at the line reading "ExecuteNonQuery()" and one in my stored procedure. When I run the app in debug mode, my break point in the stored proc reads "this breakpoint will not currently be hit. No symbols have been loaded for this document." When my breakpoint is hit in the .Net code, execution goes from the ExecuteNonQuery line straight to the next line of .Net code - no hitting of my breakpoint in the stored proc.
I have SQL debugging enabled for the .Net project. I have "Enable SQL/CLR debugging" enabled for the data connection to my database in Server explorer. My debugger is attached to Managed (4.0), Native and T-SQL processes (confirmed via the Attach to Process dialog in the debug menu).
The sql server instance and the VS instance are both on my local machine, and I am an administrator of it. I am running the app from Cassini and it is running under my own account. I am running VS2010 V 10.0.40219.1 sp1 Rel and SQL Server 2008 with SP 2 installed on a 64 bit Win2k8 machine.
Help, please - anyone! I have wasted 2 days on this!
I know this is an old question but I thought I'd provide the following work-a-round solution which will allow you to debug the Stored Proc and may be of value to someone else who comes to this question. Hopefully you'll find the steps of value!
Suggested steps:
Run SQL Server Profiler (e.g. From within SQL Server Management Studio (SSMS) - select the menu item Tools -> SQL Server Profiler).
With SQL Server Profiler connect to your local SQL Server instance.
Click the Run button on the Trace Properties window.
NOTE: You should note that SQL Server Profiler will now be monitoring activity on your local SQL Server instance (e.g. Stored Proc executions etc.).
As before put a break-point set on the ExecuteNonQuery() statement.
Run your .Net code which should hit the break-point noted above.
Before executing the break-point ExecuteNonQuery() statement go back to SQL Server Profiler and clear the trace (using CTRL+Shift+Del or clicking on the Clear Trace Window button.
Now within VS execute / step-over the ExecuteNonQuery() statement.
Within SQL Server Profiler note that a trace of the Stored Proc is now captured (along with any params).
Within SQL Server Profiler simply copy the trace results (i.e. Stored Proc with params).
Open a new query window within SSMS.
Ensure to connect to your local instance Database and start debugging by Alt+F5 or from the menu Debug -> Start Debugging.
You should now hopefully be able to debug your Stored Proc as desired!
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
How can I debug stored procedures in SQL server 2005.
It appears that in SQL Server 2005 you need to use the Visual Studio IDE - see this SO post.
This may have been changed in later service packs (because frankly, removing that from the management studio seems like a silly idea).
In SQL Server 2000 you could use Query Analyzer (right click procedure, debug)
In SQL Server 2008 debugging is back in SQL Server Management Studio (now an option in the toolbar).
Of course, the classic, tried and true way is to cut the contents of the procedure into a new query window, create the parameters you want, then use print and select statements to figure out what may be going wrong.
Use Visual Studio, by making a Data Connection to your SQL box, but don't do it on a production server, because it pauses execution using all kinds of scary low-level locking techniques. It will cripple SQL on whatever server you do it on, so do it on your local machine only if possible.