I have three SQL Server 2008 boxes, call them A, B & C. Servers A & B each have a linked server to server C. The linked servers use the exact same linked server setup on both A & B. Both connect to C using the exact same login information. The login has the sysadmin role assigned to it on box C. Both were configured with RPC and RPC OUT set to true. Both can perform SELECT, INSERT, UPDATE, DELETE with no problems whatsoever. C has Allow remote connections and Require distributed transactions checked.
The problem comes when I try to execute stored procedures. A->C works fine, but when I try to run from B, I get the error:
Msg 7201, Level 17, State 4, Line 1
Could not execute procedure on remote server 'C' because SQL Server is not configured for remote access. Ask your system administrator to reconfigure SQL Server to allow remote access.
I have been completely unable to figure this out. I have checked and rechecked the linked server configurations. They are identical on both A & B. I have run test after test and every one works fine from A, but B always gives the error.
When a stored procedure is executed, it runs as the security context of the user who created the stored procedure, not the user who is executing it. It is considered a security feature.
It may be that the account used to create the stored procedure on server B does not have the correct rights while the account used to create the stored procedure on server A does.
Recreating the stored procedure on B with another account may solve the problem.
Related
I want to put the logs in some stored procedures in our database to monitor the working of stored procedures. I am new to SQL Server 2008. The logs should be created on the production server.
I had tried this link:
http://www.codeproject.com/Articles/18469/Creating-Log-file-for-Stored-Procedure
but get the error message:
The EXECUTE permission was denied on the object 'xp_cmdshell', database 'mssqlsystemresource', schema 'sys'.
Please provide me some needful.
First of all are you sure you want to log data to text file? May be it will be better to store log into separate table ?
If you want to work with text file:
Look at description xp_cmdshell
The Windows process spawned by xp_cmdshell has the same security rights as the SQL Server service account.
Check the security rights for this account.
xp_cmdshell can be enabled and disabled by using the Policy-Based Management or by executing sp_configure.
Check you have it enabled.
EXEC sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
EXEC sp_configure 'xp_cmdshell', 1
GO
RECONFIGURE
GO
When it is called by a user that is not a member of the sysadmin fixed server role, xp_cmdshell connects to Windows by using the account name and password stored in the credential named ##xp_cmdshell_proxy_account##. If this proxy credential does not exist, xp_cmdshell will fail.
You need to create proxy account.
EXEC sp_xp_cmdshell_proxy_account [MyDomain\SQLServerProxy], 'usdcu&34&23'
Add permissions to use this SP:
USE master;
GRANT EXECUTE on xp_cmdshell to Current_user
Here is a more detailed information.
granting permissions using the master database to the object should do
Use Master
grant execute on xp_cmdshell to 'user'
Using xp_cmdshell for logging is bad for both security and performance. Please delete that codeproject link from your browser and forget you ever saw it. Seriously, it is badness.
If you want to log calls to procs, either:
Set up a table for this (as demas also suggested). You can have a DATETIME field defaulted to GETDATE() or GETUTCDATE(). You can have a field for the Proc Name, a field for parameters. Whatever.
or
Use SQLCLR to create a stored procedure that does a simple File.Write of the info. You can use Impersonation (something xp_cmdshell can't do) to have the security context be that of the person running the proc and not the Log On account of the SQL Server process. This approach is far more efficient and contained than xp_cmdshell, even when not using Impersonation.
or
Do a combination of the log table + SQL CLR [or something else]: You can log to the table for immediate writing. And then set up a SQL Agent job to archive entries over X days old to a file using SQLCLR or some other means. This way the table doesn't grow too big with info that is probably older than you need anyway for researching problems that are currently happening.
Please excuse my ignorance, I am relatively newish to SQL so hope you can help. I have a SSRS 2008 report that when ran refers to a stored procedure which inturn references a couple of tables. One of the table referenced is on a linked server. All appears to work fine when I run directly on the server, either via Visual Studio or the client interface but as soon as I deploy the report and execute via my desktop the report dataset fails? Message received is:
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
I have provided execute rights on the stored procedure and select rights to the database table on the linked server.
If I omit the linked server table from the stored procedure, all works fine??
I have access to a SQL view on say a server called vuk030 and i wish to write and run a stored procedure on a server called vuk386. My question is how to write the sql to access the data in the view on vuk030 as it has a username and password.
the vuk030 server is sql server 2005 and the vuk386 is 2008
The best way is to set up a linked server from vuk030 to vuk386 and enabling RPC over the linked server to make it possible to run stored procedures.
Setup linked server:
http://msdn.microsoft.com/en-us/library/aa560998(v=bts.10).aspx
RPC:
http://msdn.microsoft.com/en-us/library/ms186839(v=sql.105).aspx
I have been trying to migrate a SQL Server 2005 database to MySQL 5.5.29 and having trouble with the reports done with Crystal Reports 2010. I can use the set datasource location to migrate the tables (I do have to do each one individually and rename it before it will migrate) but I got it done.
However, I'm not able to update the stored procedure as I get the message:
Database Connector Error: 'HY00:[MySQL][ODBC 5.1
Driver][mysqld-5.5.28-lof]SELECT command denied to user ... [Database
Vendor Code: 1142]
I'm using the same ODBC Source as used for the tables so I don't know what I have to do to update/migrate the stored procedure. I tried to create a new report and add a stored procedure but get the same message.
Any ideas?
Thanks,
Vic
Based on the error message, the user the report is being executed as genuinely does not have access to the specified table.
The MySQL bug report Escaped wildcard in DB name prevents user from granting database permissions may shed some light on why permissions may not be applied as you think they are when the db name contains an underscore.
This is a restriction by the provider and they refuse to change it. Because of this I am not able to include stored procedures in a Crystal Report.
I am currently trying to build a process for checking SQL and MYSQL databases and am almost there thanks to the much help I have received on here. My last issue and I am hoping that its an easy one is the following. I have a SQL Server 2014 installation talking to a MYSQL database over a linked server. I am able to run a select over the linked server without any issue now but when I run a stored procedure passing in some date variables I get the following error
Msg 7399, Level 16, State 1, Line 22
The OLE DB provider "MSDASQL" for linked server "TESTCONNECTION" reported an error. The provider did not give any information about the error.
Msg 7350, Level 16, State 2, Line 22
Cannot get the column information from OLE DB provider "MSDASQL" for linked server "TESTCONNECTION".
The Code I am running is
SELECT * FROM OPENQUERY ( TESTCONNECTION,'CALL
usp_sync_check_3(''2016-11-13'',''2016-11-15'');' )
Am I not calling the stored procedure correction, when I run it from MySQL everything works fine, can anyone offer any suggestions. I have been googling but nothing that seems to fix my issue.
Thanks P
I have now figured this out, I was not passing in the schema name as well for the stored procedure, once I had done this everything worked as it should. Thanks PJD