I am facing a strange issue. I have a linked server on ServerB for ServerA
Now, when I am calling a stored procedure from ServerB like
EXEC [ServerA].[Db].[dbo].[SpName] #Param1 #param2
I am getting error that
The EXECUTE permission was denied on the object 'SpName', database 'Db', schema 'dbo'.
But now when I am executing below query it is returning me result:
SELECT *
FROM [ServerA].[Db].[dbo].[tblName]
I don't know that why I am not able to execute stored procedure from ServerB. I am Db_Owner on both the server.
Screenshot of Linked server security
Linked server catalog
If a linked server query fails, the things to check are (in rough order of probability):
Try logging in locally on the linked server to test access directly. If you have no local access, obviously you won't have it through the link either.
Verify the correct credentials as used when accessing the linked server, and not another user you're not expecting. You can check this with EXEC ('SELECT USER_NAME(), SUSER_NAME()') AT [Server]; if the user name is not what you're expecting, check your linked server definition for the correct login mappings. If you can't access the server at all (any query fails), you have other problems (like Kerberos authentication issues if you're using integrated authentication).
Perform a sanity check that you're accessing the correct server with EXEC ('SELECT ##SERVERNAME') AT [Server]. The network name of a linked server can be changed using sp_setnetname, so the name you use to a access the server isn't necessarily the machine name.
If all else fails, dropping and recreating the linked server definition is always an option, but obviously this could disrupt production work.
Related
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 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
First, I know the syntax of calling a procedure on a linked server and I am familiar with the RPC and RPC Out server options at a basic level. What I am being told is that a procedure I created cannot be seen by navigating the tree of the linked server.
One caveat is I do not have access to the server where this person is working which is linked to the server on which I have the procedure - I hope that is clearly stated. At this time he is getting the "not configured for RPC" error on execution and I have told him to check the linked servers options. So ultimately, do the RPC linked server options control whether the procedure can be seen?
I've been told that other views can be seen. Also, I am confident it is not a permissions issue. The user involved has access to a role which has access to my procedure.
Thank you for your time.
In the Linked Server, Properties, Server Options there are two RPC settings.
Set them both to true.
What do you mean by do not have access?
You cannot Connect to that server?
That is how I tested this.
Connect to any server, create a Linked Server back to yours, and test.
This is true:
In the Linked Server, Properties, Server Options there are two RPC settings.
Set them both to true.
You also need to verify that the credentials used inside the linked server connection has rights on the linked server.
Grant connect, and access to the database that has the stored procedures that you need access too. You will then grant execute to the procedures you need to run.
If you have connection issues, open SSMS using the credentials you have used to create the linked server on the database server you are trying to link from and verify connectivity and database access. If you can see the objects your after, then the linkedserver connection is the problem. Try creating a new one and see if you have better luck that way.
For linked servers, I see how it is possible to change the "remote query timeout" configuration to hint a call to a linked server should complete or rollback within the specific timeout value. This appears to work across the SQL Server engine--is it possible to change the hint within a stored procedure, so that a specific stored procedure could run longer if needs to, but all other non-hinted SPROCs would timeout quicker if they run long?
Linked Query Timeout is discussed here:
http://support.microsoft.com/kb/314530
Example code to set it to timeout in 3 seconds is here:
sp_configure 'remote query timeout', 3
go
reconfigure with override
go
Not really advisable to change it within a stored procedure. remote query timeout is a global server setting when altered with sp_configure, so changing it in a stored procedure affects all remote queries for all linked servers on the server.
Additionally, executing sp_configure requires the ALTER SETTINGS server permission, which typically only sysadmin and serveradmin have. Granting these permissions to a data access account would be a security concern since they could potentially take your server down with sp_configure commands.
What I would suggest is creating a second linked server with a different name that you would use with just this one stored procedure. You can, in SSMS, configure a query timeout for each individual linked server. Adding a second linked server would enable you to query the same server with different linked server client settings. You might need to create a DNS CNAME to accomplish this if you're using plain SQL Server Linked Servers.
I'm trying to create table from view from remote server (calling procedure UPDATE_PROC), like this:
SELECT *
INTO table
FROM [remote_server\database].DATABASE.dbo.view
And it works perfectly.
Problem is, when I try to create a new job, which is calling the previously worked stored procedure UPDATE_PROC
exec UPDATE_PROC
It doesn't work and reports:
Executed as user: NT AUTHORITY\SYSTEM. The OLE DB provider "SQLNCLI10" for linked server "remote_server\database" does not contain the table ""DATABASE"."dbo"."view"". The table either does not exist or the current user does not have permissions on that table. [SQLSTATE 42000] (Error 7314). The step failed
So it seems to be same, but it isn't. What I'm doing wrong?
UPDATE:
Remote server is SQL Server 2005, job is on SQL Server 2008
I'm logged as sa user. Procedure is working always, job calling stored procedure never
Job isn't run as sa user, but I don't know which user and where should be defined to execute the job propery....
It seems to me that's a security issue. User under which the job is running doesn't have permissions to access table on the remote server.