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]
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.
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.
I have a SQL Server database project in Visual Studio and I have dropped an existing stored procedure. I also have a database locally where that exact stored procedure exists.
When I run a schema compare from within Visual Studio on both, in the resulting schema compare window, I can see the stored procedure that will be dropped in the generated deployment script. However, when I invoke sqlPackage.exe from a Powershell script, the generated deployment script does not contain a drop statement for the stored procedure. Interestingly, when I make a change to the stored procedure, then it is included in the generated deployment script with an alter statement.
Why is sqlPackage.exe omitting the drop stored procedure statement when I remove it but including it for a change? I feel it's a parameter setting I need to feed to sqlPackage.exe but they seem to be opt out, not opt in (https://msdn.microsoft.com/library/hh550080(vs.103).aspx#Anchor_7).
Below is my command from Powershell:
& 'sqlPackage' '/Action:Script' "/SourceFile:$sourceDacpacFile" "/TargetFile:$targetDacpacFile" "/OutputPath:$outputPath" "/TargetDatabaseName:$targetDatabaseName" "/p:AllowIncompatiblePlatform=$allowIncompatiblePlatform" "/p:BlockOnPossibleDataLoss=$blockOnPossibleDataLoss" "/p:DropIndexesNotInSource=$dropIndexesNotInSource"
Take a look at the property DropObjectsNotInSource
Specifies whether objects that do not exist in the database snapshot (.dacpac) file will be dropped from the target database when you publishto a database. This value takes precedence over DropExtendedProperties.
The default is False see: DacDeployOptions.DropObjectsNotInSource Property
I am using MSSQL Management Studio. I have creates a stored procedure using CREATE PROCEDURE and am now working on it with a script that now contains ALTER PROCEDURE. The procedure name following this statement is underlined in red, and the editor says it cannot find it. Nevertheless, the stored procedure appears in the left-hand tree view, and I can right-click it and run it without error. When I do this, the temporary script that is generated to run the stored procedure...
EXEC #return_value = [dbo].[SP_V00_CreateABCTable]
also underlines the name in red.
I don't understand how the editor can claim the object doesn't exist but then runs it without error. Does anyone have any idea what may be going on?
Or you can also refresh your local cache form here
This happens frequently if you have created the stored proc since you opened the SQL manager studio session. Refreshing the Object Explorer does not refresh this data for the syntax checker. Opening a new instance of studio will refresh the intellisense data.