SSIS Flat File Folder Permission - ssis

I am using SSIS to export a CSV file to a folder location that needs credentials for access so we can SFTP it to a client.
What permissions do I need to set? I don't see any way to set username and passwords in the Flat File Destination.
Currently I get a error when trying to export the file:
Warning: 0x80070005 at Data Flow Task, Flat File Destination [2]: Access is denied.
Error: 0xC020200E at Data Flow Task, Flat File Destination [2]: Cannot open the datafile "\\SERVER\FOLDER\Dropoff\ELIGIBILITY.CSV".
Error: 0xC004701A at Data Flow Task, SSIS.Pipeline: Flat File Destination failed the pre-execute phase and returned error code 0xC020200E.
I thought I had generated a file in a folder with permissions before but I don't do a lot with SSIS and don't remember what I did.

SSIS simply executes as the user running the package. So if you are running from your dev machine it is your Windows credentials which will need access.
If you are running from a SQL Agent Job then the SQL Agent Service Account user will need permissions (or use a proxy)

Just in case this helps anyone, I was also getting this error and could not figure out why it would execute when running the package directly (in my case through VS) but not from SQL Server Agent. All the permissions seemed correct. I finally tried deleting the existing file (I had it set up to overwrite the data in the existing file in that directory) and re-ran the job and it worked. After that, it has worked fine. So there seems to have been some permission issue (maybe?) or conflict with the file I originally created through VS and the file created through the SQL Server Agent job.

Related

SQL Agent Export Job is failing with Access is Denied error

I have created an export task to export a view into an excel file onto a folder location. The task runs fine and exports to excel in the correct place. I ahve now saved this task in SSIS.
I am now trying to create a SQL agent scheduled job to run the task daily. I have SQLServerAgent and MSSQLServer access to the folder location however it keeps failing with the error:
Executed as user: NT Service\SQLSERVERAGENT. The process could not be created for step 1 of job 0x3FF5419F86864B47A653A928777E56DE (reason: Access is denied). The step failed.,00:00:00,0,0,,,,0
I have looked this up online and there were suggestions to try ticking the use 32bit runtime checkbox which i have also tried and still keep getting the same error.
Does anyone know what i can do to get the SQL agent job to run successfully?
I found the cause. The reason was I gave SQLServerAGent read/write access to the folder but it needed modify permission. Once i gave it modify it worked fine

SSIS EXECUTE TASK not working as expected through sqlserver agent

I have created a SSIS Execute Task package to export CSV and write into d:/ drive
It works when i execute from SSIS.However when i run from SQLServer agent, the job shows sucess but the export file is not available in the location
Can anyone please advise if anything i am missing.
Thank you
I think that the issue is that the SQL agent doesn't have access to the file system location. Make sure that SQL service account has needed permissions:
Configure File System Permissions for Database Engine Access

Flat File Source Failing When Deployed and Executed

I am trying to create a simple SSIS package that can be deployed to a VM on another domain (same computer) that has SSIS on it. The package that I have created will transfer data if I simply run the data flow from SSDT on the source computer, but when I try to deploy and execute it, it appears to have 2 errors. The first being that it cannot open the datafile "C:\SSIS\Product Data.txt". The second being that the Flat Files Source 1 failed the pre-execute phase. I think that the second error is caused from the first. Does anyone know how to create a package that can transfer data to another computer without the flat file source?
Thanks in advance!
C:\SSIS.... will refer to the local C drive of the computer that is executing the package. So if you have it on the VM it would be at the \VM\C$. Typically it means 1 of 2 things.
1) The file path is not correct and you are not referencing where the file actually is.
2) the user you are executing the package as does not have permission to that file.
So where is the file is it on the C drive of the machine you are executing the SSIS package on? The answer to that wasn't clear in your question.
Second how is the file being executed? manual execution such as DTS_Exec? SQL Agent? T-SQL? If manual then the user logged in executing the task must have permission, if SQL Agent then the sql agent service account and possible the sql server service account have to have permission to the file, and T-sql sql server service account needs to have permission.
When it is local file path then a local user or domain user will work for the service accounts. If network path then the local user used for service account won't work and you will need to setup a way to run as a different credential.

SSIS Lookup to Excel file causes export to excel destination to fail

I have an SSIS package that is all tested and working fine except for one part. When I try to export data to an Excel file that was previously used in a Lookup function, it returns this error:
[Excel Destination 1 [3340]] Error: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80040E09.
I have tried copying the file and then exporting the data to the copy and it works fine - it only fails when exporting to the same file used in the lookup. I have a feeling that the Lookup function uses the OLE DB connection that I've created for it and leaves it open, so that when the Excel Connection Manager tries to access the file to write on it, it is denied.
I've tried altering the OLE DB connection to the Excel file to be read-only, and to use full cache and no cache on the Lookup, but none of this has helped. Appreciate any suggestions.
I do believe your assumption is correct, SSIS is taking an exclusive lock on the Excel file when it opens and isn't sharing that lock with itself. A quick rework would be to add a second SSIS package. This one populates a Cache Connection Manager with all of the Excel data. Persist the cache file to disk
Then in your existing SSIS package, change the Lookup to use the cache file instead of Excel directly. Now the only lock taken should be for the Excel Destination.
You then would need to make your invocation pattern
RunNewCachePackage
RunNormalPackage

"Unspecified Error" when clicking on 'Name of Excel Sheet' for a Excel Source Task

I've created an Excel connection. When I create a data flow with an Excel destination and click 'Name of Excel Sheet' I get an "Unspecified Error". When I look under 'Show Advanced Editor' of the destination I see the following error:
Error at blah [Connection manager "DestinationConnectionExcel"]: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005.
An OLE DB record is available. Source: "Microsoft JET Database Engine" Hresult: 0x80004005 Description: "Unspecified error".
Error at Insert blah [Destination - blah [199]]: SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "DestinationConnectionExcel" failed with error code 0xC0202009. There may be error messages posted before this with more information on why the AcquireConnection method call failed.
Exception from HRESULT: 0xC020801C (Microsoft.SqlServer.DTSPipelineWrap)
I've read through a tons of other post and nothing seems to help. I've tried setting the 'DelayValidation=True' on all the Jet Engine related task. While this allows me to run the package without any errors, I can't edit or change anything. I also can't create new tasks with Excel.
I've already tried to set 'Run64BitRuntime = false" and that also isn't helping.
Another note, The problem is intermittent. I've been able to work with Excel tasks fine one time after a reboot, then another time its all failing as I described.
Any help would be appreciated. Thanks all
I encountered a similar issue, and the resolution was two-fold for me. First, make sure certain dlls are properly registered on your dev machine:
Paraphrased from SSIS 2005: Using Execute SQL Task to work with Excel Connection Manager
Please check whether the following files exist:
C:\windows\system32\odbcjt32.dll
C:\windows\system32\msjet40.dll
C:\windows\system32\msexcl40.dll
C:\Program Files\Common Files\System\Ole DB\oledb32.dll
C:\Program Files\Common Files\System\ado\msado15.dll
If they are, please manually register them. Run each of the following commands from command prompt:
Regsvr32 "C:\Program Files\Common Files\system\Ole DB\oledb32.dll"
Regsvr32 "C:\Program Files\Common Files\system\ado\msado15.dll"
Regsvr32 "C:\windows\system32\msjet40.dll"
Regsvr32 "C:\windows\system32\msexcl40.dll"
Then, update any folder/file paths referenced in the SSIS package. I kept changing the Excel Connection Manager object to point to the correct file, but the change would never "stick." Another developer directed me to look at the list of Variables in the SSIS package. Right-click anywhere in the package designer and choose "Variables" (based on the 2008 version). In the list of variables, check if there are any paths that are being used. If you find any, verify that they exist on your machine or change them to use your own local paths.
After following these two suggestions, I was able to open the Excel file and choose the target sheet in the Excel Connection Manager window. And, the SSIS package runs successfully in my local environment.
I take it the path to the excel workbook is correct? I also had problems when I had opened and saved the excel workbook I was using as my destination in excel. I think if you create the workbook from within SSIS it might use office web tools. Perhaps you could try to recreate the workbook within SSIS.
I got similar problem,make sure connection manager is connected to MicrosoftExcel-64 bit which is same as SQL SSIS version.
Otherwise add Microsoft.ACE.OLEDB.12.0 provider in your linked server, not in your local machine.
And also check if you have Microsoft excel present in your server again not on your local machine
If local machine and SQL Server installed on the same machine then its fine.