I have a collection of .sql files containing ddl for various database objects.
For example:
User.sql
Group.sql
GroupUser.sql
Is there a way I can use a stored procedure to easily/elegantly load/execute these files in sequence? For example, GroupUser.sql depends on the existence of User and Group, so I need to execute the .sql files in the order listed above.
I know I could concatenate the contents of all of the .sql scripts above into a stored procedure, but I would prefer to take a more modular approach. I could also put each script into its own stored procedure but I'd rather not clutter the stored procedure collection in my app database with DDL setup scripts.
From SSMS, go to the "Query" menu, and select "SQLCMD Mode". Once there, you can run commands like this. I script out stuff like this all the time.
use test
go
:r "D:\SomeDataDirectory\SomeSQLFile.sql"
EDIT: Didn't see you wanted to do this within a stored procedure. That's a bit of a dicey proposition. Assuming you have permissions to execute it, you could put the same SQLCMD code in calls to xp_cmdshell, but in many circumstances that won't be an option for you unless you've got admin-like permissions on the server.
Related
Is there an alternative to xp_cmdshell BCP to write to a file from MSSQL?
Some context: This is to be built into a stored procedure called by an external program. I do not have the luxury to work through executable files, export functions of ssms, or any such things which require more than the calling of this stored procedure.
The reason; there's a lot of odd stuff on this server to do with user rights, and I'm not the SA. I cannot create the ##xp_cmdshell_proxy_account## (let alone assign credentials to it), and xp_cmdshell 'whoami' returns a user noone has ever seen or heard from. I've tried creating a new user based on an existing windows user and granting xp_cmdshell execute rights to it, but this still did nothing. I'm not sure if I don't have the rights or if it's something else.
So long story short, I'm fed up with trying to get this to work on this environment and am looking for an alternative. Is there one?
Write a SQL Agent Job and kick it off with sp_start_job. You can control the identity the job uses with a SQL Agent Proxy.
Or write an SSIS package, deploy it to the SSIS Catalog and run it from your stored procedure.
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.
I'm writing a SQL script which is executed as part of a series of SQL scripts. I cannot access the other scripts nor do I have control over the "series-execution"-logic.
I want to change the database within my script (USE someDB), however, I want to make sure that after my script has run the previous DB is the current DB again. Is there some kind of pushd/popd for database usage? An alternative, e.g., by somehow writing the current DB into a temporary variable?
I don't know about any pushd/popd functionality, but the way to get the current database name is use the DB_NAME() function like this:
SELECT DB_NAME()
In Server Explorer (within Visual Studio) I can expand a database, right click on the Stored Procedures folder, and select "Add New Stored Procedure"
I can then add an SP and try to execute it. However, when I try to save the Stored Procedure (so that it will be subsequently available in the list of Stored Procedures for that database), it gives it the generic name "dbo.Procedure.sql*", even though I gave it another name, such as:
CREATE PROCEDURE [dbo].[duckbilledPlatypiOfIowa]
When the save dialog displays (wanting to save the .sql file to my Documents folder), I can rename it what I want, but it is not available in the list of Stored Procedures in the database.
How can I get it to be available there?
Note: If I right-click the Stored Procedure pane and select "copy path" (or some such), I do get what seems valid, namely:
MSSQL::/PROSQL42/PlatypusData/sa/SqlProcedure/dbo.Procedure.sql
But again, you see the generic "dbo.Procedure.sql" name. Yet no "dbo.Procedure.sql" displays in the list of Stored Procedures after saving, either.
So again, what do I need to do to save my new Stored Procedure into the database I'm working with?
CREATE PROCEDURE [dbo].[duckbilledPlatypiOfIowa]
and the definition that follows is the TSQL which will 'save' it to the database.
If you run that line again, you should get an error saying that it already exists.
To verify that it does, right-click the 'Stored Procedures' node and choose 'Refresh'.
If it doesn't appear in the database you think you're working with, check the connection of the window you're in.
To be sure, add
USE [DatabaseName]
GO
Before executing your CREATE PROCEDURE [dbo].[duckbilledPlatypiOfIowa]
I have a massive insertion operation on a number of tables for a base-line database. I was trying to organize this task in multiple SQL scripts for individuals tables and dependent tables. I need to call the scripts in a sequence from the main post deployment SQL script.
Any ideas?
If there isn't already a post-deployment script in your project (possibly called Script.PostDeployment.sql) then add a new item of type SQL Server > User Scripts > Post-Deployment Script.
In this script, reference your insert scripts using a relative path like below. The scripts will be run in the order you list them. Example:
:r .\InsertScripts\script1.sql
:r .\InsertScripts\script2.sql
(Ignore any errors/warnings that say this is invalid syntax. Visual Studio treats these like placeholders and at build-time the contents of each script will essentially be inserted into the main SQL file.)