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.
Related
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.
I was wondering if it is possible for SQL Server to check a directory for files and run a stored procedure. I did some research and found this, but I am wondering if there is a way to do what I want WITHOUT SSIS.
EDIT: After reading my post, I realized I should have been more specific. Is there a way to AUTOMATICALLY or set SQL Server to check for files in a directory and run a stored procedure?
You can use xp_cmdshell to run file related commands. To get a directly listing:
exec xp_cmdshell 'dir *.csv';
You can also use bulk insert to load a file from disk into a table and take actions based on the loaded contents.
Normally you'd use the File Watcher Task with SSIS. But you can also use SQL Server Agent to schedule a task for periodic execution, schedule a task with Windows Task Scheduler, or configure a stored procedure to runs at startup with sp_procoption that pauses (using waitfor) between processing times.
In SQL Server filestream storage, I find these guids in my Windows SQL Server folder. I don't know if they can be obtained by using SQL scripts.
Where are these guids coming from ?
You can. There are multiple ways of accomplishing this, from simple, specific CLR applications to the undocumented stored procedures Microsoft has included.
DISCLAIMER: The following procs are limited to permissions that the
account SQL Server Agent runs under.
xp_dirtree - undocumented
Returns a tabular result set from the directory path. Second parameter sets the depth of subdirectories to traverse (0 means return all subdirectories). Third parameter is BIT that decides whether to include files in result set.
EXEC master.sys.xp_dirtree '<directory_path>', 0, 1
xp_fileexist -undocumented
Great for checking single locations pre-steps before inserting files in a script.
EXEC master.sys.xp_fileexist 'C:\FilesCompare_SQL Files\FilesCompare.txt'
I have a large query running that loops over multiple stored procedures. Based on business rules, I'm calling the appropriate stored procedures for each record that is in my loop.
The problem is that those stored procedures sometimes generate multiple result sets. What happens then is that in SQL Server Management Studio, the 'results pane' gets filled up with data, it slows down SQL Server Management Stidion and in the end Management Studio even crashes with an out of memory exception. Is there any way in which I can suppress the results from showing up?
You can also execute it from a command line using OSQL, and specify a logfile:
osql -E -S ServerName -d DBNAme -q "EXIT(<QUERY STUFF HERE>)" -o PathtoLogFile.txt
run the query as a job in Sql Server Agent.
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.