P R W


I have found SSIS is showing some strange behaviour when dealing with share names for file connections.

I have been using Package configurations and file connections to pick up excel files are using the name of the Share as the path to the file location.

What is strange is that SSIS appears sometimes to successfully see the file and other times fails with the error "....does not exist"

eg I have run a package successfully picking up these excel files using the share name. I have then run the same package IMMEDIATELY again using the exact same files from the same share location and it will then fail with the above error.

Has anyone else seen this behaviour




Re: SSIS flakey dealing with share names

Paul


how do you execute your packages dtexec server agent .. this could be a security problem

when you ran your packages twice.. you did exactly the same.. no difference

could you maybe post the whole error message

- paul






Re: SSIS flakey dealing with share names

P R W

The package was run through dtexec, but I can't see it is a security problem.

If it was why did it succeed the first time (I checked the log file. Both times it ran under the same account).

The packages were run exactly the same, absolutely no difference. Literally, the run was repeated almost immediately after.

Error was:

The file name "......filename...." specified in the connection was not valid.

This I find very strange behaviour.






Re: SSIS flakey dealing with share names

JayH

P R W wrote:

I have found SSIS is showing some strange behaviour when dealing with share names for file connections.

I have been using Package configurations and file connections to pick up excel files are using the name of the Share as the path to the file location.

What is strange is that SSIS appears sometimes to successfully see the file and other times fails with the error "....does not exist"

eg I have run a package successfully picking up these excel files using the share name. I have then run the same package IMMEDIATELY again using the exact same files from the same share location and it will then fail with the above error.

Has anyone else seen this behaviour



Similar behavior has been reported before. In the thread linked below, the share was to a Unix server. I assume the error is either coming from flakiness in the share, or maybe due to file locks from someone editing the file. The resolution to that problem was to copy the file locally using the File System task, rather than trying to read it via the share. I wouldn't consider this a workaround so much as a good practice.

http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=1425500&SiteID=1




Re: SSIS flakey dealing with share names

P R W

I did consider it is possibly that the files are being locked, but in my testing there was no user/program accessing those files.

In the link it appears the person was not using unc path names which I am.

Why is copying to the local drive to read considered best practice





Re: SSIS flakey dealing with share names

JayH

P R W wrote:

I did consider it is possibly that the files are being locked, but in my testing there was no user/program accessing those files.

In the link it appears the person was not using unc path names which I am.

Why is copying to the local drive to read considered best practice



See now, "best practice" is a loaded term, and I didn't say that. I said it was a good practice. I don't have a particular reason, but I believe it dials out a lot of complexity. If you're using a Windows share, you're probably in better shape than someone using a Unix share, but if you're having trouble like that, the first thing I'd do is copy it local.

I don't see how using UNC path names makes any difference.