I wish to set a breakpoint in a stored procedure in SSMS and have it triggered (to start debugging) when the procedure is invoked from my external application. Is this feasible? If so, how can I set it up?
No, this isn't possible. You can debug only your execution of stored procedures, either in SSMS (excluding the most recent v.18, because debugging has been removed) or in Visual Studio, but you cannot attach to someone else's session.
You can modify the stored procedure to dump debugging information to a log table and check the log after the execution. You can also monitor another session via Extended Events or Trace/Profiler.
One side note - debugging in production is not recommended. For example, while your code is stopped, it will hold locks, which can cause blocking issues.
Related
I have created a stored procedure in the New Query window. I made sure that my database for the new procedure matches the database for which I created the stored procedure.
I executed the creation of the stored procedure successfully. I then refreshed the window structure and it shows the new created stored procedure (in this case, spGetEmployeesByGenderAndSalary
but when I try to run it in the query window, it doesn't show up in the suggested features.
Not to say it doesn't acknowledge it's existence. If I simply type out
EXEC spGetEmployeesByGenderAndSalary it runs fine
I just don't understand why it doesn't show up in the automated suggestions box.
Update- apparently it appears if I close out SSMS entirely and reboot it, now it shows up fine. Is it always like this, though? Is it some kind of glitch? Anyone else had this issue?
Also, what's this feature called? Intellisense?
I am trying to get some data off a server which I only have read access on using an analytic stored procedure that has not been promoted there yet, so I am using it manually like
CREATE PROCEDURE ###MyProcedure
Then in another query window I can run the new temporary procedure just fine. But soon as I close the query window which has the create statement, the temporary procedure is gone. To make matters worse, there are multiple subroutines that therefore require me to spam my workspace with open query windows to use this approach.
I thought globally-scoped temporary objects were retained until all referencing connections were closed. The only difference in my connection details (using F4 properties tab) between query windows in SSMS is the SPID, but I see the same connection name.
This is a known feature of using local and global stored procedures; that they only exist while the connection exists. Since each query window uses its own connection, the procedures are thus dropped when their defining query windows are closed.
Instead of using CREATE PROC ##YourSP... Try making it persistent in tempdb: CREATE PROC tempdb.dbo.YourSP.... it'll then persist until the SQL Server restarts (as tempdb is rebuilt every time the service is started).
Edit: if you're using using SQL Server 2016+, you could also, instead, use CREATE OR ALTER PROC... This'll stop the CREATE generating an error if the service hasn't yet been restarted; and thus the SP hasn't yet been lost.
Let's say I have a number of "autoexec" stored procedures, i.e., marked with:
exec sp_procoption 'myproc', 'startup', 'ON';
Is there a way to start SQL Server so that the autoexec procedures are not executed at startup this time? I need to do this sometimes for certain maintenance operations.
Thanks.
From the fine manual.
Although stored procedures are set for automatic execution
individually, the SQL Server scan for startup procs configuration
option can be set using sp_configure to prevent all stored procedures
from executing automatically when SQL Server starts. To skip launching
these stored procedures, specify trace flag 4022 as a startup
parameter. If you start SQL Server with minimal configuration (using
the -f flag), the startup stored procedures are not executed. For more
information, see Trace Flags.
Is there a way to start a stored procedure that has been configured for automatic startup via sp_procoption without having to restart SQL Server?
Occasionally I'll need to make an adjustment and have to KILL the running session to do so, but I cannot seem to locate a way to turn it back on again without restarting SQL Server.
I've tried the most obvious options, like calling the procedure from a query window, but that's not the correct way to go about this as it requires the query to remain open.
I've searched both here and on Google to no avail. I suspect I'm not asking the right question.
Thanks in advance.
I created a batch file to run SqlMetal and generate Linq2Sql data classes, check into source control triggering a build, etc... I'd like to have this script run anytime there is a DDL change in Sql Server 2005.
Running the batch file via xp_cmdshell works fine outside of a trigger, like this:
exec master..xp_cmdshell 'd:\dev\db_triggers\generatedataclasses.bat', no_output
But when it runs as a trigger, it always times out connecting to the database, causing all DDL to fail. Here's my trigger:
CREATE TRIGGER [Trig_SqlMetal]
ON DATABASE
FOR DDL_DATABASE_LEVEL_EVENTS
AS
exec master..xp_cmdshell 'd:\dev\db_triggers\generatedataclasses.bat', no_output
I'm looking for advice on two points:
Make this work. For some reason it always fails when in the trigger, and doesn't when not in a trigger. Doesn't appear to be security related since it runs as LocalSystem in both cases.
Make this happen asychronously so that failures and timeouts in SqlMetal don't cause DDL update failure. I've tried wrapping the batch file with another and a "start cmd.exe /c otherbatch.bat", but when running through sql server it seems to ignore the start (works fine from DOS). I could certainly write a polling process to look at some table and pickup events, but I'd prefer this be trigger based to make it less complex (or am I doing the opposite :) ).
Your batch is probably being blocked because it tries to query data about the tables being created, but they are still locked inside a transaction (the trigger is part of the implicit transaction SQL Server starts for any DDL/DML statement), that will complete only after the trigger finishes.
The only "almost" practical way of asynchronous execution in SQL Server 2005 or higher that I know of is Service Broker. Look for "Service Broker Internal Activation".
In practice it is a bit complex to set it up properly, so you might well choose to go for the pooling option.