I'm running SSMS 12.0.2000.8
If I use the SSMS query editor to create a stored procedure (such as the one below) the comments before BEGIN are removed when I execute/save it:
CREATE PROCEDURE myproc
/* Say goodbye to this comment */
#var1 int -- this comment will disappear too
AS
BEGIN
/* This comment is safe */
select 'hello' -- this too shall endure
END
A colleague is running the same version of SSMS and has no such problems. If I execute one of his scripts using sqlcmd.exe the comments get stripped then too. I presume there must be a global setting that I need to change but I have no idea where it might be.
I was experiencing the same issue and found that it was caused by Tools -> Options -> SQL Server Object Explorer -> Scripting -> Convert user-defined data types to base types.
When this is "True" I lose my comment blocks. When "False" my comment blocks came back.
After observing some other strangeness (namely with execute as caller being added to my scripts), I did some Googling and discovered the answer:
delete \Users\[user]\AppData\Roaming\Microsoft\SQL Server Management Studio\12.0\sqlstudio.bin
WARNING: You will lose your current list of memorized SQL Servers/usernames/passwords.
I tested this with SQL Server 2008 and SSMS 12.0.2000.8, and this was the result after "Script stored procedure as" - > "Create to" -> "Clipboard":
CREATE PROCEDURE [dbo].[myproc]
/* Say goodbye to this comment */
#var1 int -- this comment will disappear too
AS
BEGIN
/* This comment is safe */
select 'hello' -- this too shall endure
END
GO
Have you tried checking with sp_helptext if the comments are in the procedure before you use the scripting tool?
I also checked the options, can't find anything there related to comments, or stripping away anything like that.
While the specified solutions didn't work for me, it certainly pointed me in the right direction.
For me, the behavior was only occurring on a single SQL Server connection, and it was because "Always Encrypted" was set to "enable". When I disabled it, my comments remained in the stored procedure code.
Screen Shot of SSMS 18.4
Related
Recently I noticed that a stored proc we are trying to profile failed to appear in the profiling output.
After adding in SP:StmtStarting and SP:StmtCompleted events, I noticed the TextData reported as
-- Encrypted text
.. but the stored procedure is not encrypted.
This has only recently started happening - we used to profile this SP perfectly fine, and I can't figure what has changed.
Any suggestions would be gratefully received.
UPDATE: The SP is definitely not encrypted. I've created new SP's on the box, and I see SP:BatchStarting event with the new SP's name. With the old SP, I don't see the BatchStarting event, but I do see the statements within the SP executing.
However I need to see the values of the parameters the SP is being called with, as they are table types. Originally I could see the table types being instantiated and populated before the SP is called.
So I figured this out in case anyone finds it useful.
I have table type parameters to this stored procedure. One of the parameters is passed a lot of data (i.e. a C# DataTable with >5000 rows). Without this quantity of data the stored proc profiled fine.
I guess there must be some cut-off at which point Profiler does not show all of the data being passed in.
Someone has altered the stored procedure and added the 'WITH ENCRYPTION' hint, which will cause this behavior. Alter the stored procedure and remove that hint and you'll start seeing the text of the proc again.
Also to note, if you don't have the original code, you will not be able to decrypt the text of the proc to issue the ALTER statement, so hopefully you have that handy.
Here's a decent run down of this option: Options for hiding SQL Server code
Moving the Trace Properties from the default of OnlySP(<your database here>)(user,default) to TSQL or TSQL_Replay unveiled the SQL being used for me, ... Go to File|Properties... and change the [Use the template:] drop-down combobox.
I must have some permissions wrong, but I can't figure out how. The following code is simplified but I can't even get this to work
CREATE FUNCTION ufTest
(
#myParm int
)
RETURNS int
AS
BEGIN
DECLARE #Result int
SELECT #Result = #myParm + 1
RETURN #Result
END
GO
Then I just want to be able to call the function from a stored procedure:
CREATE PROCEDURE dbo.[uspGetGroupProfileService]
#id int
AS
BEGIN
SET NOCOUNT ON;
DECLARE #otherId int;
SET #otherId = dbo.ufTest(#id);
END
SQLServer keeps telling me that it can't find dbo.ufTest. It shows up under [DB]\Programmability\Functions\Scalar-valued Functions but I can't figure out how to use it.
Anybody have any idea what I'm doing wrong?
EDIT
As indicated by the selected answer below, you can't always trust the SSMS Intellisense. One thing that you can try, other than just trying to execute the script, is forcing an Intellisense refresh with CTRL + SHIFT + R
https://blog.sqlauthority.com/2013/07/04/sql-server-how-to-refresh-ssms-intellisense-cache-to-update-schema-changes/
Works for me.
Try CREATE FUNCTION dbo.ufTest ...
I assume your default schema can't be dbo and it's ending up in a different schema. Otherwise the only explanation I can think of is you might need to grant permissions on it.
Script out the UDF and check the schema name. It's probably not dbo. I would change the UDF definition to specifically include dbo. In other words:
CREATE FUNCTION dbo.ufTest
Had the exact same problem and mine got fixed by simply restarting SQL Server Management Studio.
Just posting this in case anyone else did everything right and is still not able to call his function.
I just had an issue where this was the error and all of the advice on this column was failing as well.
Be sure double check your function declaration type and usage of that type.
I declared a return-type table and tried to call it with Select functionName() where I needed to use SELECT * FROM functionName()
As a last resort if any of the above and especially #jrdev22's answer did not help you (and left you stumped why), restart the SQL Server service in Configuration Manager since restarting the SSMS alone sometimes does not reset everything (e.g. similar to when creating a new login instance but not being able to login with it).
SQL Server Configuration Manager> SQL Server Services > SQL Server > Restart
Try calling it with a select instead of a set. And you checked that out belongs to the dbo schema?
It appears it might be a bug in the query editor. The Function appears in the tree in the right place but even naming the function dbo.xxxxxx the function doesn't appear in the query editor until you close and open a new session, then it appears if you type in dbo.
If you change the name of the function the old non existing fuction is avalable but not the new name. Refresh doesn't fix this only closing the session and starting a new one.
Why I say this might be a bug is that the permissions properties for Table function includeds a blue link to the schema properties but the Scalar functions it doesn't. So it may be a deeper lying bug in the way the schema is set up in the first place for which there may be a work around. Or maybe the schema in the database I am working on has not been set up correctly.
Hopefully someone else can shine some light on this issue.
If you are unable to find the function that you have just created there are two reasons for it.
you are using the wrong function name you need to add dbo.function name to get it.
I've also found one more issue like even though correct name is entered and also it is existing in the object explorer after refreshing you are unable to find it when you are trying to use the function.
In this case simply close the sql server and reopen it and you should be able to see the function.
Is there any way that we can Hide Store Procedures in SQL Server from users?
For SQL Server 2005 and above, don't give them permissions. Then, "Metadata visibility" means it's not visible and not runnable. It makes no sense to want to hide them but give them permissions.
Note: db_owners and syadmins will always see them.
Otherwise your only option is to encrypt the stored procedure as mentioned (which is easily defeated using free tools).
You can encrypt the text of the stored procedure, if that is what you mean.
CREATE PROCEDURE my_procedure
WITH ENCRYPTION
AS
BEGIN
SELECT *
FROM my_table
END
The encryption is not unbreakable, but at least it is a first line of defence.
I am stuck in a rather strange problem with SQL Server 2005, which throws
"SET QUOTED IDENTIFIER should be on when inserting record"
(using as SP) to the particular table. This worked fine earlier but is throwing this error randomly.
I have verified the SP. We didn't manually specify SET QUOTED IDENTIFIER settings inside, so it must be ON by default.
Can someone clarify what could be the problem?
The table must be created with SET QUOTED IDENTIFIER ON right? I didn't check the table script yet.
I have observed that this problem only occur with the SPs doing insert or update on a date column (modifiedAt)... A sample value is '2009-08-10 06:43:59:447'..
Is there a problem with the values passed?
After a long struggle we were able to fix this problem. I just wanted to share the reason.
Our build team maintains a separate in-house tool to deploy scripts, which internally triggers the SQLCMD (shell) utility to execute T-SQL scripts in a db.
Here is the culprit: by default, QUOTED_IDENTIFIER is OFF when running in SQLCMD mode!
Every script run through this tool is created with QUOTED IDENTIFIER OFF. We are the only module which uses indexed views. All the remaining stories you know well in my previous posts :(
NOTE: I am going to vote everyone's post as useful.
Script the stored proc, ensure/change SET options, run the ALTER PROC to ensure SET QUOTED IDENTIFIER ON is set.
Why?
The setting of "SET QUOTED IDENTIFIER" is defined at creation time for stored procs and is always "ON" for tables. Source, BOL.
When a table is created, the QUOTED
IDENTIFIER option is always stored as
ON in the table's metadata even if the
option is set to OFF when the table is
created.
When a stored procedure is created,
the SET QUOTED_IDENTIFIER and SET
ANSI_NULLS settings are captured and
used for subsequent invocations of
that stored procedure.
The default for connections can be defined at the server level (sp_configure 'user options') or database level (ALTER DATABASE). For SSMS, it's under "Tools..Options.. Query Execution..SQL Server..ANSI". It's also the default for client libraries too (except DB-LIb).
Now, it you open an SSMS Query Window and start typing "CREATE PROC.." then it uses SSMS settings when you run the code.
And SET QUOTED IDENTIFIER can not be set at run time inside the stored proc. Show me the a reference before you disagree... From the MS BOL link above:
When executed inside a stored
procedure, the setting of SET
QUOTED_IDENTIFIER is not changed.
You have to work hard to run any code with this OFF... so the most likely fix is to ALTER or re-create the stored proc.
I was just reading this article by Erland Sommarskog, The Curse and Blessings of Dynamic SQL, and it includes the following paragraph in regards to the SET QUOTED IDENTIFIER setting:
The default for this
setting depends on context, but the
preferred setting is ON, and it must
be ON in order to use XQuery, indexed
views and indexes on computed columns.
Does your stored procedure make use of XQuery, indexed views or indexes on computed columns at all?
In SQL Server 2005, SET QUOTED IDENTIFIER is OFF by default, not ON (unless using an ODBC or OLE connection...see this for more information).
You do not need to create the table with SET QUOTED IDENTIFIER ON to use it.
All you need to do is add SET QUOTED IDENTIFIER ON to the beginning of your SP to enable it for the run of the procedure (and make sure that if you don't wish to leave it on, you have SET QUOTED IDENTIFIER OFF to switch it back).
EDIT
I stand corrected. According to this MSDN Page, SET QUOTED IDENTIFIER is ON by default (unless connection with a DB-Library application.
I am maintaining a classic ASP website that has a SQL Server 2005 backend. For a small piece of new functionality I wrote a stored procedure to do an insert. This is the only user stored procedure in the database.
When I attempt to call the stored procedure from code I get the following error:
Microsoft OLE DB Provider for SQL Server error '80040e14'
Could not find stored procedure 'InsertGroup'.
/newGroup.asp, line 84
The DB uses SQL Server authentication. When I connect to the DB server in Visual Studio using the same user/pw as in the connection string the stored procedure is not visible but all tables are.
The user has datareader and datawriter roles and explicit execute permission on the stored procedure.
What am I missing?
UPDATE: My apologies, the server admin misinformed me that it was a 2000 server when it is actually a 2005 server (running on Windows Server 2003 x64).
Walk of shame:
The connection string was pointing at the live database. The error message was completely accurate - the stored procedure was only present in the dev DB. Thanks to all who provided excellent answers, and my apologies for wasting your time.
You may need to check who the actual owner of the stored procedure is. If it is a specific different user then that could be why you can't access it.
Sometimes this can also happen when you have a stored procedure being called with parameters. For example, if you type something like:
set #runProc = 'dbo.StoredProcedure'
exec #runProc
This will work, However:
set #runProc = 'dbo.StoredProcedure ''foods'''
exec #runProc
This will throw the error "could not find stored procedure dbo.StoredProcedure 'foods'", however this can easily be overcome with parantheses like so:
set #runProc = 'exec dbo.StoredProcedure ''foods'''
exec (#runProc)
make sure that your schema name is in the connection string?
There are 2 causes:
1- store procedure name
When you declare store procedure in code make sure you do not exec or execute keyword
for example:
C#
string sqlstr="sp_getAllcustomers";// right way to declare it.
string sqlstr="execute sp_getAllCustomers";//wrong way and you will get that error message.
From this code:
MSDBHelp.ExecuteNonQuery(sqlconexec, CommandType.StoredProcedure, sqlexec);
CommandType.StoreProcedure will look for only store procedure name and ExecuteNonQuery will execute the store procedure behind the scene.
2- connection string:
Another cause is the wrong connection string. Look inside the connection string and make sure you have the connection especially the database name and so on.
I had:
USE [wrong_place]
GO
before
DECLARE..
Could not find stored procedure?---- means when you get this.. our code like this
String sp="{call GetUnitReferenceMap}";
stmt=conn.prepareCall(sp);
ResultSet rs = stmt.executeQuery();
while (rs.next()) {
currencyMap.put(rs.getString(1).trim(), rs.getString(2).trim());
I have 4 DBs(sample1, sample2, sample3) But stmt will search location is master Default DB then we will get Exception.
we should provide DB name then problem resolves::
String sp="{call sample1..GetUnitReferenceMap}";
One more possibility to check. Listing here because it just happened to me and wasn't mentioned;-)
I had accidentally added a space character on the end of the name.
Many hours of trying things before I finally noticed it. It's always something simple after you figure it out.
I had the same problem. Eventually I found why. I used a code from web to test output of my procedure. At the end it had a call to Drop(procedure) so I deleted it myself.
If the error message only occurs locally, try opening the sql file and press the play button.