SQLServer cannot find my user defined function function in stored procedure - sql-server

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.

Related

SQL Server SQLCLR function receives parameter error after copying from one DB to another

I am trying to copy the send email assembly from one database to another. I clicked on script assembly as create to and created it in the new db.
When I try to send an email with the function in the newer db I get the following error:
The parameter 'fileName' cannot be an empty string. Parameter name: fileName
How can I copy the assembly across databases?
Some details:
Both DBs are on the same instance
Both DBs are owned by the same login
Using SQL Server 2016
Assembly is marked as UNSAFE in both DBs
Both DBs have TRUSTWORTHY enabled
T-SQL wrapper object is a scalar function / UDF
Function is being called the same way in both DBs
How can I copy the assembly across databases?
So far I am not seeing how this is a SQLCLR issue. You clearly copied the Assembly and the T-SQL wrapper object else you would be getting T-SQL errors instead of a .NET error.
I clicked on script assembly as create to and created it in the new db.
Given that you scripted out the T-SQL wrapper object and you are getting an error related to an input parameter, you might be running into a bug that causes defaults for NVARCHAR parameters to not script out correctly:
SSMS scripting CLR stored procedure NVARCHAR parameter NULL default as N'' (empty string)
Execute the following in both old and new DBs to make sure that all parameter definitions are the same, including any potential default values (paying close attention to rows that have a 1 for [has_default_value]):
SELECT [name], [user_type_id], [max_length], [is_output],
[has_default_value], [default_value]
FROM sys.parameters prm
WHERE prm.[object_id] = OBJECT_ID(N'dbo.ObjectName')
ORDER BY prm.[parameter_id];
If you find any differences, you will need to update your CREATE statement to include the correct default value(s). For example, if you have:
#SomeParam [nvarchar](1 - 4000) = N``
Then you will need to update that part of your T-SQL script to instead be:
#SomeParam [nvarchar](1 - 4000) = NULL
And then re-run the CREATE (you might need to either first DROP the existing T-SQL wrapper object, or change the CREATE to be ALTER).
Please vote for that Feedback bug report that I linked above. Thanks!
For more info on working with SQLCLR in general, please visit: SQLCLR Info

SSDT/SSIS Execute SQL Task not populating variable with query output

My Execute SQL Task uses a simple query that should be returning a single value. I want to write that value to a variable so that I can use it in a data flow task later but the result never seems to get written to my variable.
The SQL statement is simple:
select max (rec_id) from [dbo].[RX_BILLING_TEST]
and I believe that I've set up the task correctly:
When I execute the task, it completes successfully but the variables window shows that the value of my variable didn't update. I set breakpoints on variable value changed and on post execute but that didn't help.
As much as I hate errors, this is a case where I would appreciate getting one to point me in some direction. Any ideas what might be wrong?
In a similar case there are many things you have to check:
Try adding an alias to the aggregate function
select max (rec_id) AS Max_Rec_Id from [dbo].[RX_BILLING_TEST]
Check that your package doesn't have more than one variable User::v_Recid with different scopes. or that User::v_Recid scope's is Execute SQL Task. (it must be the Package)
Test your SQL Command using Sql Server Management Studio
Try adding the database name to your Command
select max (rec_id) AS Max_Rec_Id from [MyDB].[dbo].[RX_BILLING_TEST]

SSRS 2014 issue with dataset after deployment

My report is running without a sweat on my dev environment. I was a happy man.
When deployed on another server, I have the following issue (see below) (less happy now )
The error is:
The variable name '#choix_de_l_adresse' has already been declared.
Variable names must be unique within a query batch or stored
procedure.
I've checked the parameters for the dataset adresse1. Nothing substantial came out (see image below).
I thought it may be related to a case issue with my sql (see below) but nothing striking jumps off
DECLARE #choix_de_l_adresse VARCHAR(38)
SELECT JohnJack.Siren,
CASE WHEN JohnJack.Adresse1_Eco IS NULL
THEN '' WHEN JohnJack.Adresse1_Post IS NULL
THEN '' WHEN (JohnJack.Adresse1_Eco IS NOT NULL OR JohnJack.Adresse1_Post IS NOT NULL)
AND #choix_de_l_adresse = 'Adresse Postale'
THEN Adresse1_Post
ELSE Adresse1_Eco END AS adresse1
FROM JohnJack
The only workaround I've been able to find out is to delete the dataset and to recreate it from scratch.
Update: When I'm using ssrs query builder to run the query batch, it is running fine
Do you think using a stored procedure would help? I read somewhere that text was not a good fit and when possible, a stored procedure would be better.
Have you seen the following issue and were you be able to fix it without deleting and recreating your dataset? If the answer is yes, how did you do it?
I managed to solve my issue.
I created a stored procedure, put my sql code inside and ... voilà ! all the rows I was looking for, were retrieved

SSMS removing pre-BEGIN comments from my stored procedures

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

A replicated SQL Server stored procedure returns different results

I had created a new stored procedure from an existing one. all I did was copy the old one and changed the name.
Now when i run both in the query analyzer, i get data from the original but the new one does not return any data.
It could be with permissions but both are set to public. Any thoughts?
check ansi-nulls value? they can casuse a headach. hard to tell without seeing the code but as a general debug rule; break it apart into its basic queryies and see where the issue is introduced or where it starts to diferentiate from results of the original stored sprocedure
Sorry if my question appears naïve, but... how did you actually make the copy?
I have only used SSMS to work with DBs so far and am oblivious of other interactive tools, if there are any. As to SSMS, a mere replicating is often done in this scenario: sp_helptext [proc name], then copying the output into a new query window, changing the name and voila (i.e. 'executing the script'). The permissions are peeked at in the original proc's properties and usually added using the same or a new script.
It seems so trivial that I feel a bit guilty to put it here. Anyway, that method has never failed me so far. What is yours then?
Sorry, this of course doesn't answer your particular problem with the already copied SP. I just thought maybe you wanted some help in the more fundamental problem of its replicating.
Creating script and re-replicating the sp worked. it could have been the proc's owner or permissions related. dont feel like debugging any more after I got that working.

Resources