This issue was addressed in a prior post, and I have a very similar situation, however it is sufficiently different that a new post is justified.
I have an SSIS package with a For Each file loop. In Visual Studio 2017, the package behaves exactly as expected in debug mode. However, once I deploy the package to my SQL server and run it from there, I receive "The For Each file enumerator is empty. The For Each File enumerator did not find any files that matched the file pattern, or the specified directory is empty." The package itself exits with success, this error logged as a warning, and suffice to say, my target table remains empty.
Unlike the previous poster experiencing this issue, I have been using a UNC path for my source folder (values genericized):
I have validated that the SQL Account and SQL server itself have rights to my target share and files. I have changed the Integration Services service to use a known good domain account. I do not see any access denied errors, etc. What am I missing?
UNBELIEVABLE. Here is the answer. While I can run the SSIS package in dev from VS2017 on my workstation, once published to the SQL server, the job fails if I execute it from SSMS on my local workstation. However, the job succeeds if I run it from SSMS on the SQL server itself. Same domain, same accounts, same DNS. Ughh. I sure hope this saves someone a few gray hairs.
Related
Background
Created package in BIDS.
Deployed to SSMS
Package writes files to a CSV file in a network fileserver.
The default name of the package's flat file destination is $path\workcsvout.csv
Package derives filename from an expression
Issue
When I configure and run from SSMS, it fails with Error DFT -Extract to File:Error:Cannot open the datafile "........\DerivedFilename.
Troubleshooting
Verified the file exists in directory - used flat file destination temp filename, before derived filename - still failed
changed name to file it was trying to open - still failed
I am running job from my login in SSMS, via SSISDB - Projects - Package - .dtsx package - Execute
See pictures below and advise if more information is needed.
Thanks
Ensure Visual Studio isn't open after attempting to either run the package directly from the Integration Services Catalog as I have found that VS can hang onto a connection to the files you are writing to and it can throw similar errors.
Ensure the account configured for the package has sufficient permissions in all the areas it needs to write to.
After VS is closed and permissions are all set in step 2, try executing the package directly inside the Integration Services Catalog in SSMS. If this works, move to step 4. If this doesn't work, troubleshoot the errors and ensure security is all setup properly and you are executing the package with the same account.
If you are here, I will assume you want to schedule the package. Ensure that the owner is the same account used in step 2. Check the "Run As" account in Step in the job, if that account is not the same as step 2 then you either need to make it the same or give that account the same access as the account used in step 2.
I went through this troubleshooting process and it solved my issue. I also was building files on a general UNC file path like \servername\folder\folder without needing to do any local business with \servername\d$\folder\folder that other people recommend.
I would check to make sure that your SQL Server service account has full rights to the landing folder.
After experiencing the same issue as you, I finally checked the folder permissions that were created for our SQL Server service account. Come to find out that it was missing the "Full Control" and "Modify" folder permissions. Once I granted these to our service account, the issue went away.
Folder Permissions Dialog Box
Troubleshooting:
Can you try to create file on local and then move the file using File System Task.
I was trying to pump the data which is in csv file.
Closing the visual studio and closing the csv file which was opened in another machine resolved the problem
Executed as user: NT Service\SQLSERVERAGENT. Microsoft (R) SQL Server Execute Package Utility Version 11.0.2100.60 for 64-bit Copyright (C) Microsoft Corporation. All rights reserved. Started: 16:34:44 Error: 2015-10-15 16:34:45.04 Code: 0xC0011007 Source: {068F0DFC-339B-4E9B-BFC8-EA73BF6AE23B} Description: Unable to load the package as XML because of package does not have a valid XML format. A specific XML parser error will be posted. End Error Error: 2015-10-15 16:34:45.04 Code: 0xC0011002 Source: {068F0DFC-339B-4E9B-BFC8-EA73BF6AE23B} Description: Failed to open package file "C:\Users\ssis\Documents\Visual Studio 2010\Projects\DemoProjectwithLinedLookup\DemoProjectwithLinedLookup\ImportDataMigration.dtsx" due to error 0x80070005 "Access is denied.". This occurs when loading a package and the file cannot be opened or loaded correctly into the XML document. This can be the result of specifying an incorrect file name when calling LoadPackage or the specified XML file has an incorrect format. End Error Could not load package "C:\Users\ssis\Documents\Visual Studio 2010\Projects\DemoProjectwithLinedLookup\DemoProjectwithLinedLookup\ImportDataMigration.dtsx" because of error 0xC0011002. Description: Failed to open package file "C:\Users\ssis\Documents\Visual Studio 2010\Projects\DemoProjectwithLinedLookup\DemoProjectwithLinedLookup\ImportDataMigration.dtsx" due to error 0x80070005 "Access is denied.". This occurs when loading a package and the file cannot be opened or loaded correctly into the XML document. This can be the result of specifying an incorrect file name when calling LoadPackage or the specified XML file has an incorrect format. Source: {068F0DFC-339B-4E9B-BFC8-EA73BF6AE23B} Started: 16:34:44 Finished: 16:34:45 Elapsed: 0.172 seconds. The package could not be found. The step failed.
Follow the below steps to resolve the issue.
On the Start menu, point to
All Programs, point to Microsoft SQL Server 2008 R2, point to Configuration Tools, and then click SQL Server Configuration Manager.
In SQL Server Configuration Manager, click SQL Server Services.
In the details pane, right-click the name of the SQL Server Agent instance for which you want to change the service startup account, and click Properties.
In the SQL Server Agent Properties dialog box, click the Log On tab, and select one of the following Log on as account types:
Select a Windows Built-in account if your jobs require resources from the local server only. For information about how to choose a Windows built-in account type, see Selecting an Account for the SQL Server Agent Service.
NOTE: This solution applies when you are placing the dtsx package in yur local machine and the SSIS IN 32- bit mode.
Let me boil that error down to what matters:
Executed as user: NT Service\SQLSERVERAGENT
Failed to open package file "Access is denied."
Your SQL Agent account does not have access to the package. You need to change the SQL Agent account to something that has access or use a proxy account. This is the number one beginner issue with SSIS / SQL Agent
The reason it works in BIDS is because you are running it as you, rather than SQLSERVERAGENT
It has nothing to do with 32/64 bit (at this stage)
I've seen many posts suggesting to create a proxy for the agent so your agent can access the package, but I have not seen any posts addressing password protection. If you are running a job between servers requiring login credentials, this will run fine on your desktop, but the agent will not execute. By default, the ProtectionLevel under security will be "DontSaveSensitive", meaning your passwords aren't saved. So when your agent goes to run the job, it can't login to the databases. In the Control Flow, change the Security ProtectionLevel to "EncryptAllWithPassword".
Go back into Management Studio and try to run your job. You will be prompted to enter the password. My error code suggested the need for a proxy, but this was the actual culprit in the end.
Make sure that the path to the SSIS package used in the step is accessible within the executing context - i.e. Beware of network paths, where you mean to point to local paths relative to the executing context.
I am relatively new to SSIS packages Package is a File system task to rename and move a file.
Package runs correctly from SSIS store but whe I run it as asql server agent job it doesnt move or rename file but shows successful. What am I doing wrong
When executing the package from the store, you are likely executing the package under your own domain credentials, which probably have permissions on the folders/files impacted by the package.
When executing from the server agent, it likely does not have those same permissions on the files/folders. That would be the first thing I would check, but having additional information as to the resources being manipulated and user accounts used could potentially shed more light on the situation.
I am using an SSIS package to get a text file from a secure Unix server. One of the steps in the package ftp's the file to a Windows file share using a Flat File Connection. I have specified the connection using the full path name: \\servername\foldername\filename.
The package runs fine on my development machine; however, I am experiencing a problem when the package runs as a service under SQL Server Agent. This is how it will have to run in Test and Production. The service has been given rights to the server and the folder, but since the folder is a hidden folder it has been appended with a $.
So the actual connection string for the Flat File Connection is: \\servername\foldername$\filename.
Could the dollar sign be causing the problem for SQL Server Agent?
I am running out of ideas and I have almost exhausted my search on the Internet. Stack Overflow is always my last resort. I hope someone can help.
This problem has been resolved. There is no issue.
The job had insufficient permissions. The network administrators told us they had taken care of it, but after we had ruled everything else out, they checked again.
Tried to open an SSIS project I had been working on today and received this lovely error:
Unable to generate temporary class (result=1)
error CS0009: Metadata file 'c:\WINDOWS\assembly\GAC_MSIL\System.Xml\2.0.0.0_b77a5c561934e089\System.XML.dll' could not be opened -- 'No metadata was found.'
Anyone know why this happens and how to correct it, I've Googled and haven't found any valid solutions relating directly to SSIS. It is only happening with BIDS 2008 and SSIS project types and I tried the same packages (as well as creating a new one) on my other machine and it was fine.
Any ideas? Thank you.
Since you cannot actually browse to that directory I used Command Prompt on another machine to copy the System.Xml.dll and then transfered it over to the problem directory with Command Prompt on the machine I was getting this error on.
That simple.