I created a stored procedure in a database called DBA_Test. I went to another server and tried to execute this stored procedure using
EXEC *LinkedServerName*.DBA_Test.dbo.spLoad_Clients_Monthly_Filings
When I try to execute the query, I get the following error:
Server 'LinkedServerName' is not configured for RPC.
When the line is in the query window of SSMS, the DBA_Test is underlined in red and hovering over it shows a message:
Could not locate entry in sysdatabases for database 'DBA_Test'. No entry found with that name. Make sure that the name is entered correctly.
I have everything spelled correctly and the stored procedure is listed in the database as seen here:
I tried executing the stored procedure on the same server, but from another database, and it ran fine. Every other server I switched to gave the red line error saying that the database could not be found in sysdatabases. I have all the linked servers working correctly.
When you create linked server you need to set RPC (and maybe RPC out):
Regarding your second question, sometimes SSMS doesn't correctly parse linked server objects
Related
I want to execute a MSSQL stored procedure from a derived table within a domain.
I've tried below two commands, but both give the error message below.
EXEC SP_NAME
CALL SP_NAME
The query is not valid. A derived table query must start with SELECT and contain at least 4 words, or an attribute placeholder {attribute('attributeName')}
Screenshot:
https://imgur.com/a/jBUP6tH
I've successfully executed an SP from within the report designer (Jasper Studio), but everything seems to work differently in the server environment. I've read throught several manuals, including one specifically about domains, but it only mentions that executing a stored procedure is possible but doesn't show any example syntax (page 43: server domains manual). Anyone know how to get this to work?
Because I need to fill a view with dynamic data, I wrote a stored procedure to collect the data and use select from OPENROWSET('SQLNCLI','server=....;trusted_connection=yes','EXEC Stored_Procedure') as the view definition.
As far as I know you can't use variables in your view definition so that's why I choose this route.
The stored procedure collects data from a linked server source combined with native SQL Server data. The linked_server has the appropriate permissions setup for the remote user and can be successfully queried from outside SQL Server.
That works very well in a local context but when I try to use the view in a PostGreSQL foreign-table I get an ODBC error. The first errors involved the permission to execute the stored procedure by the caller's user account. After that I get stuck. It seems the connection with the server has sufficient access permissions but the OPENROWSET call to execute the stored procedure does not (no login_mapping exists).
However, if I change the SQL in the OPENROWSET command to a simple select statement (select * from db.schema.table) it works fine.
I tried to change the server in de OPENROWSET to a datasource to the local server itself, with the remote user to impersonate, but with no luck either. The same login_mapping error.
My guess is that this has something to do with the fact that the users security context is not the one used by the OPENROWSET command?
I have looked around a lot but was not able to find a solution. Can you help me?
I am fairly familiar with retrieving data from SQL Servers into Excel 2010. Recently I read the following article on allowing users to submit parameters to a stored procedure and was trying it out:
Data from SQL server
I am able to walk though all the steps of connecting to the server using the SQL Server Native Client 11.0 driver. I can call the stored procedure and return data in the Microsoft Query window (through step 8 of the instructions in the above link).
I can move through all 14 steps with ease. However, after linking the parameters to specific cells and defining the location for the data, hitting "OK" to return the data to the spreadsheet I receive the following error:
Some searching suggested that it may be a permission issue with the Stored Proc so I tried several variations of GRANT EXEC ON [dbo].[uspGLDetail_ItemNumber] TO PUBLIC. The proc I am attempting to execute is [uspGLDetail_ItemNumber].
You can see I am returning data in the Microsoft Query window:
I am not sure why the error is referencing that specific object. I attempted to check the permissions on the listed object, but do not find that procedure on our Server. Perhaps, part of the solution could be how to find the listed object in the error.
I am thinking this is perhaps more of an issues with Excel communicating to the server than a permission issue on the stored proc so was trying a few different drivers with no luck. However, I have successfully been retrieving data into excel From SQL Server with no issue for a long time.
I have a problem calling a remote Stored Procedure (RPC) on my SQL Azure, passing through a Linked Server (build on a Sql Server 2008 R2 instance: 10.50.2550.0 - x64 - Enterprise Edition).
This issue is not difficult to reproduce, and it's not really related with "calling" the Stored Procedure, but with its internal execution (I think)...
Take a look to my simple code:
CREATE PROCEDURE [dbo].[myStoredProcedure]
#AccountId INT = NULL
AS
BEGIN
DELETE FROM [dbo].[myTable];
INSERT INTO [dbo].[myTable] (Col1, Col2)
SELECT DISTINCT
Value1
, Value2
FROM [dbo].[myTableSource];
END
GO
GRANT EXECUTE ON [dbo].[myStoredProcedure] TO [myDbRole]
GO
When I launch this through my Linked Server, using this code (on a connection from my local instance, where the Linked Server has been created)...
EXEC('[AZURE_LINKEDSERVER].[myDatabase].[dbo].[myStoredProcedure] #AccountId = NULL')
...I get this error (that seems a warning!):
Message 2812, level 16, state 62, row 1
Could not find stored procedure 'sp_reset_connection'.
And obviously I checked everywhere and I'm not calling that Stored Procedure...that I think it's internally used by Sql Server.
I also tried this code, same result:
EXEC sp_sqlexec '[AZURE_LINKEDSERVER].[myDatabase].[dbo].[myStoredProcedure] NULL'
The Linked Server has "remote RPC enabled" (rpc and rpc out options are both set to True) and works great with other Stored Procedure and every other OPENQUERY code I used until now: also permissions work fine.
The strange thing is that the first part of the SP is correctly executed (I see query result count in the Messages window of SSMS), but the second is not called at all.
Can you please tell what's the SP sp_reset_connection is related to?
Do you know a workaround to call my SP without errors?
I tried everything...
SQL Azure in use has version 11.0.9231
sp_reset_connection is not an actual stored procedure it is a flag in the TDS stream that says "Reset the connection" so you can use connection pooling. It should exist on all SQL Servers implicitly but cannot be called by your code.
what type of linked server have you setup? follow this to create a linked server to azure:
http://blogs.msdn.com/b/sqlcat/archive/2011/03/08/linked-servers-to-sql-azure.aspx
I have a weird problem here.
In short to the environment we have:
There is a (newly set up) Win2003 Server with a SQL Server 2005 Express database. I connect to it via a MS Access application.
Since I switched to the new server (restored a backup from the former server on it) all SPROCs (only in Access) have a ;1 after their name, hence cannot be found.
If I try to open a SPROC in Access (dbl click in overview), it asks for the parameter, then says cannot be found.
If I try to open, say, a report based on it, same result. If I change the name of the SPROC the report is based on to the name shown in the overview ( [sprocnam];1 ) it says "cannot be found" (of course, because the names did not change as one can see in Management Studio).
?!?
keep in mind that the Access-application worked fine with the database that I backed up on another server and restored to the newly set up server ...
Your help is greatly appreciated!
edit: I found a thread on SAP.com with someone experiencing the same problem, but without a solution: https://forums.sdn.sap.com/message.jspa?messageID=7947957
I can't tell why you have got this issue, but in In SQL Server you have the ability to create Numbered stored procedures. The procedures have the same name but may contain completely different code, look at this:
CREATE PROCEDURE [dbo].[spTest]
AS
BEGIN
SELECT ##MICROSOFTVERSION
END
GO
CREATE PROCEDURE [dbo].[spTest];2
AS
SELECT ##version
GO
EXEC spTest;1
EXEC spTest;2
I resolved the issue with an update of the clients office-installation to the latest service pack.
The one employee that notified me of the problem and me got new computers last week, and thus did not have the latest updates.