I have SQL server and It has another SQL server Linked server [DEV]. Now I want call a stored procedure in Linked server and get the result value. It is always giving error. I tried below both statements none of the did not worked.
ALTER PROCEDURE [dbo].[UpdateMemebership_Lock_Count]
#v_constit_id_in as varchar(100)
AS
BEGIN
Exec ('Call [Members_Directory_Search_DEV].[dbo].[update_dirsearch_notes]
(?)',#v_constit_id_in) AT [DEV]
--Exec [DEV]..[Members_Directory_Search_DEV].[update_dirsearch_notes]
#v_constit_id_in
END
Error
Msg 102, Level 15, State 1, Line 1
Incorrect syntax near '.'.
Not sure what syntax you are used to using (CALL is used for Analysis Services, not SQL Server), but linked servers have a four part notation:
ServerName.DatabaseName.owner.object
Try:
Exec [DEV].[Members_Directory_Search_DEV].dbo.[update_dirsearch_notes] #v_constit_id_in
Related
I just found a what i think is a bug in Azure SQL. Microsoft SQL Azure (RTM) - 12.0.2000.8
Any idea what's going on here?
create procedure dummyProc
as
declare #myVar nvarchar(20) = 'data'
select myVar = #myVar
into #temp
Executing the code generates an error:
Msg 156, Level 15, State 1, Line 1
Incorrect syntax near the keyword 'PROCEDURE'.
Msg 8180, Level 16, State 1, Procedure sp_describe_parameter_encryption, Line 1 [Batch Start Line 0]
Statement(s) could not be prepared.
An error occurred while executing batch. Error message is: Internal error. Metadata for parameter '#p10c873e7e2034dd29022eb675d63dfbb' in statement or procedure 'CREATE PROCEDURE dummyProc
AS
DECLARE #myVar AS NVARCHAR (20) = #p10c873e7e2034dd29022eb675d63dfbb;
SELECT #myVar AS myVar
INTO #temp;
' is missing in resultset returned by sp_describe_parameter_encryption.
Thanks for reporting this issue. This is indeed a problem in SSMS and, sadly, it is still an issue in the latest version of SSMS 18.x.
The issue is that parameterization is trying to parameterize declare statements inside of a create stored proc statement.
We (SSMS Team) will do our best to address it in a future version of SSMS.
In the interim, the suggested way to unblock you would be to disable parametrization, by going to "Tools | Options | Query Execution | SQL Server | Advanced" and making sure that "Enable Parametrization for Always Encrypted" is unchecked.
Upgrading to 18.2 fixed the issue.
In earlier versions, using always encrypted with the query option Enable Parameterization for Always Encrypted would cause the error.
Thanks for your comments and help!
I'm writing a script in Sybase ASE where I call a stored procedure in SQL Server. The problem I have is that I'm getting an error from Sybase but not from SQL Server.
The Script in Sybase is as follows:
declare #input varchar(4000)
select #input = '111,222,333,444,555'
exec GATEWAY.MyDataBase..MyStoredProcedure #input
And this is the error:
[Error] Script lines: 1-5 --------------------------
Conversion failed when converting the varchar value '555.............................................................................................................................................' to data type int.
Msg: 245, Level: 16, State: 1
Server: GATEWAY, Line: 0
My stored procedure in SQLServer
I don't know why Sybase adds that right padding. The only way I can get it work is declaring the variable #input as varchar(255) or shorter.
What I tried without luck:
Adding a rtrim and ltrim in sybase
Setting the variable as TEXT
Adding rtrim and ltrim in SQLServer
adding a replace(#input,' ', '')
Wanted to replicate the problem in SQLServer adding the pad to the right but it still works.
The important thing is that: I can excecute it from SQLServer but it throws error from Sybase with the same input data.
Any help would be very appreciated. I guess it has something to do with the size of the varchar but no clue yet.
You can create a remote procedure in Sybase like this:
CREATE PROCEDURE "DBA"."uspSQL_CreateTicketsByCaseNo;1"( in #caseNo varchar(8) )
at 'SQL;dbName;dbo;uspSQL_CreateTicketsByCaseNo'
You can also right-click the Procedures & Functions and use the wizard to create a remote procedure. Then call the remote procedure like this:
CALL "DBA"."uspSQL_CreateTicketsByCaseNo;1"( caseNo )
It works for me.
I am migrating from SQL Server 2005 to SQL Server 2014 and one of the queries stopped working in SQL Server 2014:
select *
from openrowset ('SQLOLEDB','Server=(local);TRUSTED_CONNECTION=YES;',' exec [MyDatabase].[dbo].[MyTable]')
I get the following error message:
Msg 11529, Level 16, State 1, Procedure sp_describe_first_result_set,
Line 1
The metadata could not be determined because every code path results in an error; see previous errors for some of these.
Msg 4902, Level 16, State 1, Procedure sp_describe_first_result_set, Line 1
Cannot find the object "#MyTempTable" because it does not exist or you
do not have permissions.
dbo.MyTable and #MyTempTable are not real names.
What could cause this error? Any help would be appreciated.
Thanks
From SQL Server 2012 onwards, you need to use WITH RESULT SETS to explicitly describe the result set:
EXEC('exec [MyDatabase].[dbo].[StoredProcedure] WITH RESULT SETS (( val SMALLINT));')
I've got a stored procedure which takes two parameters. I'm trying to use OpenQuery in SQL Server to join on the result set of my stored procedure dbo.TwoDrugs. The SQL Server is only a local machine with no one else having access. I'm trying to do
select *
from OpenQuery (AHCTW208D02,'exec [i 3 sci study].dbo.TwoDrugs ''X'',''Y''')
and I get the error
Msg 7357, Level 16, State 2, Line 1
Cannot process the object "exec [i 3 sci study].dbo.TwoDrugs 'X','Y'". The OLE DB provider "SQLNCLI10" for linked server "AHCTW208D02" indicates that either the object has no columns or the current user does not have permissions on that object.
I can't think of a reason why I wouldn't have permission (since I created the stored procedure), and I configured the server for data access.
When I run the stored procedure it does in fact return a result set. Any ideas on what might be the problem with this?
OPENQUERY cannot be used to execute extended stored procedures on a linked server. However, an extended stored procedure can be executed on a linked server by using a four-part name. For example:
exec AHCTW208D02.[i 3 sci study].dbo.TwoDrugs 'X','Y';
please read Remaks
Reference: http://msdn.microsoft.com/en-us/library/ms188427.aspx
In SQL Server Management Studio 2008, I created a Stored Procedure, but its not appearing in the 'Stored Procedures' list when viewing in Object Explorer.
I've also restarted the server, and restarted my machine, and tested on other machines, and the Stored Procedure still isn't appearing.
I know that this Stored Procedure exists in the system because if I execute the following query:
exec dbo.sp_Orders
I get the following error:
Msg 201, Level 16, State 4, Procedure sp_Orders, Line 0
Procedure or Function 'sp_Orders' expects parameter '#OrderID', which was not supplied.
Therefore its recognising that the Stored Procedure exists, and even returns an error about a Parameter which was not supplied.
Why is this happening and how can I access the sproc?
you can try followign to access your sp:
exec sp_helptext xxxx where xxxx is your sp name.