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 help me out to resolve this issue, I tried several options but unable to get success till now, any
help would be greately apprecaited.
I am generating one image file using xp_cmdshell on SQL Server 2008, the image is not getting generated in the excel file while doing this, the same image generates properly while running the same through command prompt and on SQL Server 2003.
So based on above scenario, I think the problem is not with the code, the problem is with some setting on SQL Server 2008 related to xp_cmdshell command.
Can you please provide me some guidance to resovle this issue, let me know if you have any questions on this.
Thanks,
Shoeb
Check the windows permissions for user, under which the sql server is run
also
check if using xp_cmdshell is not prohibited on the server level by command
exec sp_configure 'xp_cmdshell'
and check that is user running this command is sysadmin or there is set proxy account on ##xp_cmdshell_proxy_account##
See more here
I'm trying to execute the command in the Windows console:
C:\SphinxSearch\bin\indexer --all --config C:\SphinxSearch\sphinx.conf
But I get an error:
ERROR: index 'indexname': sql_connect: Can't create TCP/IP socket
(10093) (DSN=mysql://root:*#localhost:3306/test).
A data source is mysql. Before the server restart everyone works fine.
How can I fix it?
I'm having the same error 10093. It's a windows error code by the way. In my case it occurs when trying to run the indexer through the system account via a scheduled task. If I'm running it directly as administrator, there's not a problem.
According to the site above:
Either your application hasn't called WSAStartup(), or WSAStartup() failed, or--possibly--you are accessing a socket which the current active task does not own (i.e. you're trying to share a socket between tasks).
In my case I'm thinking it might be the last one, some security problem due to user SYSTEM being used in my scheduled task. I was able to solve it by using my admin user instead: in the scheduled task, I set to use my local admin account with the option to "Run when user is logged on or not" and "Do not store password". I've also checked "Run with highest privileges". This seems to have done the trick as now my indexes are rotating on schedule.
Below is the query that I am using to backup (create a .bak) my database.
However, whenever I run it, I always get this error message:
Msg 3201, Level 16, State 1, Line 1
Cannot open backup device 'C:\Users\Me\Desktop\Backup\MyDB.Bak'. Operating system error 5(Access is denied.).
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.
This is my query:
BACKUP DATABASE AcinsoftDB
TO DISK = 'C:\Users\Me\Desktop\Backup\MyDB.Bak'
WITH FORMAT,
MEDIANAME = 'C_SQLServerBackups',
NAME = 'Full Backup of MyDB';
Yeah I just scored this one.
Look in Windows Services. Start > Administration > Services
Find the Service in the list called: SQL Server (MSSQLSERVER) look for the "Log On As" column (need to add it if it doesn't exist in the list).
This is the account you need to give permissions to the directory, right click in explorer > properties > Shares (And Security)
NOTE: Remember to give permissions to the actual directory AND to the share if you are going across the network.
Apply and wait for the permissions to propogate, try the backup again.
NOTE 2: if you are backing up across the network and your SQL is running as "Local Service" then you are in trouble ... you can try assigning permissions or it may be easier to backup locally and xcopy across outside of SQL Server (an hour later).
NOTE 3: If you're running as network service then SOMETIMES the remote machine will not recognize the network serivce on your SQL Server. If this is the case you need to add permissions for the actual computer itself eg. MyServer$.
Go to the SQL server folder in start menu and click configuration tools
Select SQL Server configuration manager
On SQL server services, on the desired instance change the (Log On as) to local system
In order to find out which user you need to give permission to do the restore process, you can follow the following steps:
You need to go to your server where SQL Server is installed. Find SQL Server Configuration Manager
Next, you need to go to "SQL Server Services"
Under your SQL Server (MSSQLSERVER) instance there will be an account with column "Logon As", in my case it is NT Service\MSSQLSERVER.
That is the account which you need to add under Security tab of your source .bak location and give that user the "Read" permissions so that the backup file can be read.
Let's say your backup file is present at "D:\Shared" folder, then you need to give permissions like this:
One of the reason why this happens is you are running your MSSQLSERVER Service not using a local system. To fix this issue, use the following steps.
Open run using Windows + R
Type services.msc and a services dialog will open
Find SQL Server (MSSQLSERVER)
Right click and click on properties.
Go to Log on tab
Select Local System account and click on "Apply" and "OK"
Click on Stop link on the left panel by selecting the "SQL Server (MSSQLSERVER)" and Start it again once completely stopped.
Enjoy your backup.
Hope it helps you well, as it did to me. Cheers!
The SQL Server service account does not have permissions to write to the folder C:\Users\Kimpoy\Desktop\Backup\
I had this issue recently as well, however I was running the backup job from server A but the database being backed up was on server B to a file share on server C. When the agent on server A tells server B to run a backup t-sql command, its actually the service account that sql is running under on SERVER B that attempts to write the backup to server C.
Just remember, its the service account of the sql server performing the actual BACKUP DATABASE command is what needs privileges on the file system, not the agent.
I face the same problem with SQL Express 2014 SP1 on Windows 10.
Solution which work
Open Service by typing Services
Locate and open the SQL Server (SQLExpress)
Go to the LogOn Tab
Choose Local System Account ( Also Check for Allow Services to interact with desktop )
Click OK . Stop the service . Restart the service.
Problem solved
I was just going through this myself. I had ensured that my MSSQLSERVER login user had full access but it was still causing issues. It only worked once I moved the destination to the root of C. More importantly out of a user folder (even though I had a share with full permissions - even tried "Everyone" as a test).
I don't know if i consider my issue "fixed", however it is "working".
Just a FYI for any other users that come across this thread.
I had a similar issue. I added write permissions to the .bak file itself, and my folder that I was writing the backup to for the NETWORK SERVICE user. To add permissions just right-click what file/directory you want to alter, select the security tab, and add the appropriate users/permissions there.
Here is what I did to by-pass the issue.
1) Go to backup
2) Remove the destination file-path to disk
3) Click on Add
4) In the File name: check box manually type in the backup name after ..\backup like below where Yourdb.bak is the database backup name
C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\Yourdb.bak
5) Click on OK
Hope this helps!
I solved the same problem with the following 3 steps:
I store my backup file in other folder path that's worked right.
View different of security tab two folders (as below image).
Edit permission in security tab folder that's not worked right.
I know it is not an exact solution but using external drive paths solves this problem.
BACKUP DATABASE AcinsoftDB
TO DISK = 'E:\MyDB.Bak'
WITH FORMAT,
MEDIANAME = 'C_SQLServerBackups',
NAME = 'Full Backup of MyDB';
I have the same error. Following changes helped me to fix this.
I had to check Server Manager->Tool->Services and find the user ("Log
On As" column) for service: SQL Server (SQLEXPRESS).
I went to the local folder (C:\Users\Me\Desktop\Backup) and added "NT
Service\MSSQL$SQLEXPRESS" as the user to give Write permissions.
SQL Server is not able to access (write) the backup into the location specified.
First you need to verify the service account on which the Sql server is running. This can be done by using Configuration manager or Services.msc.
or
Use below query :
SELECT DSS.servicename,
DSS.startup_type_desc,
DSS.status_desc,
DSS.last_startup_time,
DSS.service_account,
DSS.is_clustered,
DSS.cluster_nodename,
DSS.filename,
DSS.startup_type,
DSS.status,
DSS.process_id FROM sys.dm_server_services AS DSS;
Now look at the column service_account and note it down.
Go to the location where you are trying to take the backup.In your case : C:\Users\Me\Desktop\Backup
Right click--> Properties --> Security -->
Add the service account and provide read/write permissions. This will resolve the issue.
In my case, I forgot to name the backup file and it kept giving me the same permission error :/
TO DISK N'{path}\WRITE_YOUR_BACKUP_FILENAME_HERE.bak'
I had the same issue and the url below really helped me.
It might help you as well.
http://blog.sqlauthority.com/2011/04/13/sql-server-fix-error-msg-3201-level-16-cannot-open-backup-device-operating-system-error-5access-is-denied/
Msg 3201, Level 16, State 1, Line 1
Cannot open backup device 'C:\Backup\Adventure_20120720_1024AM.trn'. Operating system error 5(Access is denied.).
Msg 3013, Level 16, State 1, Line 1
BACKUP LOG is terminating abnormally.
I verified backup folder on C drive, Is new service account is having full control access permission or not?, I realized that "Test\Kiran" service account is not having Full control security permission.
Please follow the below steps to give full control to service account:
Go to C drive, Right click on Backup folder.
Select Security tab.
Click on Edit button, new window will open.
Click on Add button and enter Test\Kiran user account and click check name button, this will validate you entered user is existing or not, if it is existing it will show the user on window, select OK.
Select you entered user name and select Full Control check box under allow.
Please check the access to drives.First create one folder and go to folder properties ,
You may find the security tab ,click on that check whether your user id having the access or not.
if couldn't find the your id,please click the add buttion and give user name with full access.
Share this folder and use UNC path, by example: \pc\backups\mydb.bak
Then You can stop share.
Not very elegant, but it resolves all permissions problems (You need to give permissions to share as well, as mentioned above)
I experienced this problem when the .BAK file was temporarily stored in a folder encrypted with BitLocker. It retained the encryption after it was moved to a different folder.
The NETWORK SERVICE account was unable to decrypt the file and gave this thoroughly informative error message.
Removing BitLocker encryption (by unchecking "Encrypt contents to secure data" in the file properties) on the .BAK file resolved the issue.
Hi you need to change the query from:
BACKUP DATABASE AcinsoftDB
TO DISK = 'C:\Users\Me\Desktop\Backup\MyDB.Bak'
to
BACKUP DATABASE AcinsoftDB
TO DISK = N'C:\Users\Me\Desktop\Backup\MyDB.Bak'
You have to add a N in front of the path works for me.
My issue was that the "File Ownership" was set to my company. I changed it to "Personal" and it worked. Right click the file and click the "File Ownership >" option and then change it to "Personal". I believe this happens with all files sent over Microsoft Teams.
If the backup destination path resides on your local machine, change the account of 'SQL Server' service to 'Local System Account', then everything must be resolved, keep in mind that the 'SQL Server' instance service is responsible to access the backup destination so the account it is running under, must have access to the destination path of your backup.
Make sure you are actually saving to a FILE and not a folder,
My problem was I was simply putting in the Folder path and not the File path
You want this
'F:\Database Backup\Pharmacy\data.bak';
You dont want this
'F:\Database Backup\Pharmacy';