Yes, full control.

<!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-alt:"Calisto MT"; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-alt:"Times New Roman"; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-1610611985 1073750139 0 0 159 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman";} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} --> My copy and move file system task works on Visual Studio but when I setup as a schedule job, it didn't work. Job ran successful. I setup job run as proxies with admin rights to do an operation system (CmdExec) tasks. Packages running on dtexec command prompt utility. Using UNC paths. Permissions on the server folders is not an issue. Turn on logging with information event, not much information provided on the log. SSIS 2005 It is pretty simple to me but it's hard to figure out why is not working.

Is it thrown an error or does it nothing? Is there some information in Jobhistory on that step?

As I said, job ran successful. No error. Job history: Date 14/07/2011 9:00:40 AM Log Job History (SSIS) Step ID 1 Server SQLSSISPROD1 Job Name SSIS Step Name Run package Duration 00:00:02 Sql Severity 0 Sql Message ID 0 Operator Emailed Operator Net sent Operator Paged Retries Attempted 0 Message Executed as user: sqlssisprod1_srvc. Microsoft (R) SQL Server Execute Package Utility Version 9.00.4035.00 for 32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 9:00:40 AM DTExec: The package execution returned DTSER_SUCCESS (0). Started: 9:00:40 AM Finished: 9:00:42 AM Elapsed: 1.732 seconds. Process Exit Code 0. The step succeeded.

From the log: Beginning of package execution. 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 was empty. Validation phase is beginning. Prepare for Execute phase is beginning. Pre-Execute phase is beginning. Execute phase is beginning. Post Execute phase is beginning. Cleanup phase is beginning. "component "Error Excel Destination" (459)" wrote 0 rows. End of package execution.

Permissions on the server folders is not an issue. To be sure you could check that with for example Process Monitor http://technet.microsoft.com/en-us/sysinternals/bb896645 Most of the time when something works in BIDS but not with SQL Server agent its a rights issue.Please mark the post as answered if it answers your question | My SSIS Blog: http://microsoft-ssis.blogspot.com

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 was empty. Maybe the For Each is not configured well

It configured like this in the post, http://www.bidn.com/blogs/MikeDavis/ssis/625/loop-through-excel-file-in-ssis

That's what I thought. The service account is a SA on the box and have full control on the folder.

Use a domain based proxy to run this package like in http://www.codeproject.com/KB/aspnet/Schedule__Run__SSIS__DTS.aspxArthur My Blog

As I mentioned in my original post, "setup job run as proxies with admin rights to do an operation system (CmdExec) tasks." Same setup as in the post, http://www.codeproject.com/KB/aspnet/Schedule__Run__SSIS__DTS.aspx

Do you use configurations?Arthur My Blog

Yes, Arthur.

Maybe your right, Christa. On my Foreach Loop Editior --> Collection I don't have expression I filled the folder and files then variable mappings. Works fine in BIDS. When I use expressions --> directory and var then I got error: [Excel Source [1]] Error: SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "Excel Connection Manager" failed with error code 0xC0202009. There may be error messages posted before this with more information on why the AcquireConnection method call failed. I set Run64BitRuntime = False.

Double check your configuration and expressions. One or both just do not setup the variables right. Like the path to the Excel file is wrong, etc.Arthur My Blog

I'm pretty sure the path are correct.

Does SQL Agent service account has enough permission on the folders?http://uk.linkedin.com/in/ramjaddu

Now, if I don't use the package config and using UNC path. I'm getting this error: [Excel Source [1]] Error: SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "Excel Connection Manager" failed with error code 0xC0202009. There may be error messages posted before this with more information on why the AcquireConnection method call failed.

That indicates a 64-bit issue. And Run64BitRuntime will have no effect. You need to tell SQL Agent to run it in 32-bits. Read more. Talk to me now on

I'm running in BIDS in my desktop. It's 32-bit.

I'm trying different approach. Encountering a connection failure to excel on BIDS when I configured as UNC Path on Excel Connection Manager on Excel file path.

But you've said you're running this package from Agent... (or trying to) Can you please post "where you are now"? You're encountering a connection failure to excel - but under what conditions? Talk to me now on

That has to be a permissions issue, or someone else has that file open. A common practice with Excel files that have the possibility of being used when the package is being run is to always copy (via File System Task) the file to a private location. Talk to me now on

I worked with our Server Admin with this issue and he proved me that it is not a permission issue. We log on as the service account on the server and the service account can move and copy files.

Hi Cool_DBA, SSIS can be a fickle beast when it comes to permissions. I want to state at the outset that I've never had much success using SSIS 2005 with proxies or other "run-as" schemes. I'm not saying it doesn't work. I'm saying I've never been able to get it to work in a way I felt comfortable deploying to Production. (My #1 test criteria for Production deployments? "Do I get to sleep at night.") It also sounds like there may be 32-bit / 64-bit issues lingering. Battling two issues at the same time is hard. Here are some suggestions for troubleshooting: If you're running SSIS 2005 from SQL Server 2005 Agent, you do not have the option to check a checkbox and run in 32-bit mode. You have this option in SQL Agent 2008 R2 (and I believe you may have it in SQL Agent 2008). You may already have this covered, but I want to reiterate: If you want to use the Excel Connection Manager in SQL Server 2005 64-bit, you have to use a command-line and call the dtexec.exe application from the <drive>:\\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn directory to ensure you're not running the 64-bit (default) version of dtexec. You can troubleshoot the ForEach Loop Container with a simple SSIS package. In the test package, set up text logging. Add a ForEach Loop Container and configure as you believe you should. (I wrote an article you haven't yet referenced here if you want another approach). You will end up with a variable that will hold the path to any Excel files found. For the sake of this example, let's assume that variable is named "ExcelFilePath". Inside the loop, add a Script Component (set to VB) and add this line: Dts.Events.FireInformation(0, "ForEach Loop Test", Dts.Variables("ExcelFilePath").Value.ToString, "", 0, True) This will write an entry into your text log file with the path to each Excel file found by the ForEach Loop Container. Test it locally first to work out any kinks, then run it in your Production environment. If this fails to find files that are present, there are at least two possibilities: 1) The ForEach Loop Container is not configured properly; or 2) You do not have permission to see the Excel files that are present. I suggest you build a small test package to iron out thses issues first. Once these are working, I would proceed with Data Flow operations and configure the Excel Connection Manager. Troubleshooting is as much art as it is science. The key is breaking things into bite-sized chunks and testing each chunk. This is always frustrating when someone is waiting for work to be complete. I highly recommend writing test SSIS packages and executing them in the intended target environment. Use text logging combined with Script Tasks to capture output. Break it down. Keep it simple. Hard-code as much as you can initially. Make sure it works in BIDS on your workstation and then deploy it the target environment. One thought: If the SSIS package will not generate a text log in the target environment, you know you have a permissions issue. Hope this helps, Andy