MisterZimbu
MisterZimbu

Reputation: 2713

SSIS DTS Package flat file error - "The file name specified in the connection was not valid"

I have a pretty basic SSIS package that is attempting to read a file hosted on a share, and import its contents to a database table. The package runs fine when I run it manually within SSIS. However, when I set up a SQL Agent job and attempt to execute it, I get the following error:

Executed as user: DOMAIN\UserName. Microsoft (R) SQL Server Execute Package Utility Version 9.00.3042.00 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
Started: 10:14:17 AM Error: 2010-05-03 10:14:17.75 Code: 0xC001401E Source: DataImport Connection manager "Data File Local"
Description: The file name "\10.1.1.159\llpf\datafile.dat" specified in the connection was not valid. End Error Error: 2010-05-03 10:14:17.75 Code: 0xC001401D
Source: DataAnimalImport
Description: Connection "Data File Local" failed validation. End Error DTExec: The package execution returned DTSER_FAILURE (1). Started: 10:14:17 AM Finished: 10:14:17 AM Elapsed: 0.594 seconds. The package execution failed. The step failed.

This leads me to believe it's a permissions issue, but every attempt I've made to fix it has failed.

What I've tried so far:

Any ideas? I'm still convinced it's a permissions issue. However, what I've read from various searches more or less says giving the executing account permissions on the share should work. However, this is not the case here (unless I'm missing something obscure when I'm setting up permissions on the share).

Upvotes: 1

Views: 13522

Answers (3)

embooo
embooo

Reputation: 1

i know this post is old, but i just faced the same problem i think you guys are using "sa" user and it does not have privilege on the folder holding the package, try to log in to SQL with windows authentication , and try to import the package then.

worked for me, hope it will work for you.

Upvotes: 0

MisterZimbu
MisterZimbu

Reputation: 2713

Oops. Looks like I had permissions set on the folder, but not on the share. Started working once the permissions were put on the share. My bad.

Upvotes: 0

Todd McDermid
Todd McDermid

Reputation: 1680

Based on your last test, it's obviously something to do with permissions and a difference between permissions your account has and those that the other accounts do. What is the protection level of the package?

Upvotes: 2

Related Questions