I have executed the following query in my local system and its works fine for normal file (files that not have read only attribute). But, when I tried this for read only file the sql server prompts 'Access is Denied'.
Declare #execmd varchar(150)
SET #execmd= 'xp_cmdshell ''del "' + '\\DFSPath\000000045401.doc'+ '"''';
Exec (#execmd)'
Property of the file to be delete
SQL server error
Can anyone help me on this?
The account that the SQL Server service is running under, does not have required access to the share, or does not have access to delete the file. Open up SQL Server Configuration Manager and update the service account to use an account that has the required access, and it should work.
Related
I migrated from SQL Server 2008 to 2019. On the old server there is set up a job, which calls a dtsx file. It needs database access, file system access because it saves tmp files to disk, and internet conneciton to send this file.
The connection string is defined followings:
<DTS:ConnectionManager
DTS:ConnectionString="Provider=SQLOLEDB.1;Password=p#ssword;Persist Security Info=True;User ID=MyUser;Initial Catalog=MyDB;Data Source=SQLServer\Instance;" />
If I run it using the Execute Package Utility it works. If I run it through the SQLServer Job, I get the error that the user is not granted to access the file system. The owner of the job is the same I am logged in and run the package using the Utility.
In the history i see:
The job failed. The Job was invoked by User Domain\RightUser.....
where RightUser is the Owner (and same as before, the same user run the package using the utility)
but the second row of the error:
Executed as user: NT Service\SQLAgent$AnotherUser.
And I have no idea where this AnotherUser comes from.
Whats wrong?
Furthermore, I don't really like the hardcoded password in the connection string, If the job run in its owner context, should it work changing the connection string to Integrated Security=True;, right?
This is a very common problem with running SSIS packages. That other user is SQL Agent, which in reality runs the package (this is the default user running the steps in jobs). Job owner has got nothing to do with running the SSIS packages. SQL Agent user name is set during the SQL Server installation. If it's omitted, the installer creates automatically a username like you described.
To the second question, yes you are right. If the user, who executes the package, has the correct permissions to the SQL Server described in the connection string, the userid and password are unnecessary. But in your case, the package is run by the SQL Agent with NT Service -level username, so it might be impossible to add that username to the SQL Server. You should set up a proper username for running the SSIS package and set it as a proxy account to the SQL Server, like described here: https://community.spiceworks.com/how_to/129293-configure-an-ssis-package-to-execute-as-a-proxy-account
I get this error when deploying a package to SQL 2012 SSISDB catalog:
A .NET Framework error occurred during execution user-defined routine or aggregate "deploy-project-internal":
System.Data.SqlClient.SqlException: The locale identifier (LCID) 9242 is not supported by SQL Server
......
I had a very similar issue (different LCID) and took me weeks to resolve it but I hope is the same issue you where having and it helps for any other users.
So somehow something got bad installed on the SQL Server, the service account that is setup to run the SQL Server Service doesn't have all the necessary permissions.
I tracked this issue down to a very specific procedure, try to execute on the SSISDB the procedure [catalog].[check_schema_version] and you should be getting the same error message you are getting.
If executing the procedure gives you the same error, then the soultion is going to be the same. You basically need to change the account that is running SQL Server Service (not Integration Services) to be a local admin, and change the Locale on the RegEdit for that Local Admin acccount to be the one you want.
TO do so, do the following:
Execute on Command Prompt the following to get the SID:
wmic useraccount where name='Administrator' get sid (Replace
Administrator by your Local Admin Account)
Go to RegEdit -> HKEY_USERS -> [SID Local Admin] -> Control Panel ->
International and change keys "Locale" and "LocaleName" for the
desired region,(in my case it was Locale 00000409, LocaleName en-US)
Open Windows Services, look for the SQL SERVER (MSSQLSERVER) and
change the running account to be your local admin
Restart the Service
That should be it. I figured all that out thanks to the combination of these 2 pages:
https://www.facebook.com/allaboutssis/posts/329497130467714
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/9f409937-772a-41bd-8270-7804fdd5b94e/failure-in-deploying-ssis-project-from-ssdt-to-sqlserver-2014?forum=sqlintegrationservices&prof=required
Also I had a similar issue with the LCID for the Palestinian State which was added recently to windows and it seems that the SSIS doesn't recognize this LCID. So changing the windows LCID to another one solved the problem (from contorl panel then regions)
I solved it in the following way.
First, check in Services which user SQL Server (MSSQLSERVER) runs as:
Next, open the Registry Editor and navigate to Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\. Find which ID the user has. In my case, the user MSSQLSERVER has the ID S-1-5-80-3880718306-3832830129-1677859214-2598158968-1052248003:
When you have the user's ID, in the Registry Editor, go to the path Computer\HKEY_USERS\[USER ID]\Control Panel\International. In my case, the path is Computer\HKEY_USERS\S-1-5-80-3880718306-3832830129-1677859214-2598158968-1052248003\Control Panel\International. There you will find two keys named Locale and LocaleName:
In my case, they had the following values:
Locale = 00000c00
LocaleName = en-SE
Change them to:
Locale = 00000409
LocaleName = en-US
Next, restart the service SQL Server (MSSQLSERVER).
After that, I was able to deploy the project:
I have an SSIS package that takes data from a MySQL database and puts it in to a SQL Server table. The connection to MySQL is ADO.net. The package runs fine in BIDS.
I would like to deploy the package to be run as a Job on SQL Server 2008. The MySQL connection requires sensitive data to be either stored within the package or held in some external configuration source. If it is stored within the package it will either by encrypted with a key specific to my windows user profile or must be protected via a password.
I have tried three methods of setting up a SQL Server Agent job to execute this pacakge, and all fail:
Using a Password
I set the ProtectionLevel of the package to EncryptSensitiveWithPassword and supply a password for the package. I then save a copy of the package to the msdb. I can then connect to SSIS and run the package, at which point I am prompted for a password.
When I try to schedule this as a job in SQL Server I am prompted to enter the password by clicking on the Configurations tab of the Job Step Properties and I can see that the /DECRYPT switch has been added to the Command Line tab. The Run As property is set to the SQL Server Agent Service Account, which is mapped to a database login that has sysadmin server role. When I attempt to start this job I get the following error:
Executed as user: DOMAIN\UserROLE. Microsoft (R) SQL Server Execute Package Utility Version 10.0.5500.0 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 12:31:30 Error: 2012-07-03 12:31:31.20 Code: 0xC00291EC Source: Get Data Execute SQL Task Description: Failed to acquire connection "DATA_SOURCE". Connection may not be configured correctly or you may not have the right permissions on this connection. End Error DTExec: The package execution returned DTSER_FAILURE
It seems that using this method the package password itself is not stored anywhere for the job to access it.
Using an XML configuration file
I then created a copy of the package and set the ProtectionLevel to DontSaveSensitive and I set up a package configuration to store the MySQL credentials in an XML file. I then save this to the msdb and then when I run the package from
Integration Services I can provide a path to the config file, and all is well. However, once again when I set up a job for the package I point to a configuration file on the server but the job fails with the same error. I am wondering whether this is because the SQL Server Agent does not have an associated windows account that would allow it to read from the XML file stored in the file system.
Using a SQL Server table configuration
This time I created a copy of the package and set the ProtectionLevel to ServerStorage. I then created a [SSIS Configurations] table in the target SQL Server database. I modified the entries in this table to contain the password for the MySQL data source. Again, the package runs successfully from Integration Services, but fails with the same error as previously when run from a job. I have checked that the SQL Server Agent is able to read from the [SSIS Configurations] table ok - I set up a standalone job to test this.
Does anyone have any suggestions about what else I should do here?
I am thinking of giving up on SQL Server Agent Jobs for this and going back to having the package scheduled simply by the windows scheduler but thought before throwing in the towel I would try here first.
I am using the method of encrypting the password by setting EncryptSensitiveWithPassword as you discribed above and don't see anything you do wrong. Remember to use option keep protection level of the original package when importing the package with integration services, but it looks like you're doing that, too.
Try setting the role SQLAgentOperatorRole to your SQL Server Agent Service Account, you didn't mention that and i am not sure if you did. This could possibly solve your permission problems. (liked to answer by commenting this, but i lack of permissions here, too :)
First of all "Northwind" and "AdventureWorksDW2008" databases attached without problem, but "AdventureWorks2008" fails with the following error.
//Msg 5120, Level 16, State 105, Line 1
Unable to open the physical file
"C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\Documents".
Operating system error 2: "2(The system cannot find the file specified.)".
Msg 5105, Level 16, State 14, Line 1
A file activation error occurred. The physical file name
'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\Documents'
may be incorrect. Diagnose and correct additional errors, and retry the operation.
Msg 1813, Level 16, State 2, Line 1
Could not open new database 'AdventureWorks2008'. CREATE DATABASE is aborted.
I did not use the default database instance "MSSQLSERVER" during install.
So where is it finding this path "C:...\MSSQL10.MSSQLSERVER...\Documents"?
go to sql server configuration manager
sql server services SQL Server(MSSQLSERVER)
change the "log on as" to "local system"
First of all you need to enable the FILESTREAM usage:
EXEC sp_configure filestream_access_level, 2
RECONFIGURE
After that you can create the DB:
USE [master]
GO
CREATE DATABASE [AdventureWorks2008] ON
( FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.SQLTRAININGKIT\MSSQL\DATA\AdventureWorks2008_Data.mdf' ),
( FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.SQLTRAININGKIT\MSSQL\DATA\AdventureWorks2008_Log.ldf' ),
FILEGROUP [PRIMARY] CONTAINS FILESTREAM DEFAULT
( NAME = N'Documents', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.SQLTRAININGKIT\MSSQL\DATA\Documents' )
FOR ATTACH
GO
Change the TRAININGKIT instance name for your instance name and check the paths after that run with sysadmin privileges.
This is my solution for SQL2008R2 :
Create folder Documents under Data folder
Start MSSQL Mgmt Studio (run as Admin)
Set Filestream Access Level to Full Access Enabled (Srv properties/Advanced)
Attach db AdventureWorks2008R2.mdf (add db and remove Log file before attaching)
just like SQL Guy! i enabled FILESTREAM from configuration manager=>services=>yourinstance=>right-click=>properties=>advanced and then i you can
remove the necessity of the log file from the attachement menu ( right click on database in sql => attach...). and it worked!
It was appearing to work, but becoming Suspect after SQL service restart. SQL Log said:
Message FILESTREAM's file system log record 'placeholder.txt' under
log folder '\?\C:\Program Files\Microsoft SQL
Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\Documents\$FSLOG' is corrupted.
Combining various suggestions found above, I got it to work (and survive service-restart without going Suspect) by:
Grant SQL service account FULL permissions to the MDF & LDF files and the Documents folder BEFORE copying them into DATA.
Delete C:\Program Files\Microsoft SQL
Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\Documents\$FSLOG\placeholder.txt
(R2 BOL hints at this, but directs it at the wrong level).
CREATE DATABASE [AdventureWorks2008] ON ( FILENAME =
N'C:\Program Files\Microsoft SQL
Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\AdventureWorks2008_Data.mdf'
), ( FILENAME = N'C:\Program Files\Microsoft SQL
Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\AdventureWorks2008_Log.ldf' )
, FILEGROUP [PRIMARY] CONTAINS FILESTREAM DEFAULT ( NAME =
N'Documents', FILENAME = N'C:\Program Files\Microsoft SQL
Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\Documents' )
FOR ATTACH_REBUILD_LOG
Solved it by below ways:
I fixed it As the .mdf and .ldf files where on different drives,
it was giving some wierd error so i attached only mdf files and the server created .ldf files on the same drive as mdf. this way i could attach it but then i took the db offline copied the log from D:\ to E:\ and then brought the db online. it worked.
and sometimes you can :
try login with Windows Authentication and
Start SQL Server manager as Administrator (right-click on the program, choose "Start as administrator")
Seems like many are having this issues, including me, and including the guy who logged this bug with MS Connect:
http://connect.microsoft.com/SQLServer/feedback/details/567193/adventureworks-2008-fails-to-attach
This is the only way I could get it to work. (Install without filestream)
Go to Download 'AdventureWorks 2008R2 OLTP Script'
Unzip and open the instawdb.sql script. Remember to set the variables at the top of the script. Run the script. This should bulk load all the data as well. Good luck!
This worked for me:
Software used-SQL Server 2008 Express R2, Windows Vista OS, Adventureworks2008R2.mdf
Place the database in the Program files(X86)\Microsoft SQL
Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA folder (or similar location
for your operating system)
All my installation files are in the default. This was done on
Windows Vista with SQL SERVER Express 2008R2. The database used was
Adventureworks2008R2.mdf.
IMPORTANT PART---After picking the database in SSMS ATTACH DIALOGUE
BOX you must Remove the log file first (within the Attach dialogue
box), (.ldf file). If you do not Remove this file the attachment
will fail with an error message.
Database attached and is working perfectly without any changes to
accounts or logins or any other steps.
In my case the problem had to do with the file I was using and the version of SQL. I have installed SQLServer2008R2 and the file I was using was AdventureWorks2008_Data.mdf. I downloaded the one from here http://msftdbprodsamples.codeplex.com/releases/view/59211 (AdventureWorks2008R2_Data.mdf) and all is fine now.
In SSIS,I had tried to deploy a package, which is for importing data from MySQL to SQL SErver 2008, at another server. When I tried to execute the Package from SQL Server, the deployment failed. The error was access permission denied for MySQL user. What is the solution for this ? should I have to set any permission ? I have installed MySQL data provider at the server.
You most likely have the username and password stored in the package using UserKey encryption.
When you deploy to SQL Server and run it, it's run as a different user, thus not being able to decrypt the passwords. You can either not save sensitive information, encrypt with password, and/or use a configuration file on your SQL Server that also contains the password in the connection string for your MySQL server.