June 3, 2011 at 9:48 am
This is a bit baffling.
My package does the following--runs a batch file that maps the z drive. It does a loop to loop through each file. The directory (z:\sharename) to loop through is specified in a package configuration. The search string is hard coded in the for each step (Mess*.csv).
I get the "for each file enumerator is empty" message when I run this package.
As a test a put the files locally in C:\localdirectory and it runs fine. So the configuration is setting the directory fine and it can see local files, and the search string is working. So it must be a problem with the share--permissions or something.
I map the drive in the batch file using:
net use z: \\ipaddress\sharenane remotepassword /USER:remoteuser /YES
(by remote user I mean a local user account on the server with the share). I am running this currently on the SQL Server but I am running it from BIDS. I am logged into the server with my domain account. If I map the drive from the command line using the above code form the batch file, I can see the z: drive and open the CSV files. The share permissions on the remote share are full control for everyone and the local security permissions are also full control for everyone.
Any ideas what is wrong--this is SQL Server 2005 by the way.
Thanks!
June 3, 2011 at 11:54 am
When you run that batch file what if any output do you get?
Also, since all you are doing is creating a security context why even map it to a drive?
net use \\address\sharename
The refer to the file path by UNC.
I think the loop can handle that.
CEWII
June 3, 2011 at 1:53 pm
I had tried mapping without a drive letter but it was giving strange behavior--when I tried to map it was telling me I couldn't map multiple drives to the same location, but when I tried to delete the location it said it couldn't find that network location. Mapping drive letters seems to work fine.
Running on the batch file on its own works fine--drive maps and I can access the files in Windows explorer.
Pretty weird. Version of integration services in BIDS is 9.00.4035.00. Any bugs in this area? Don't see why it shouldn't see the files on a mapped drive if it can see them locally. Is it possible that, even though the mapped drive step runs first, that by the time I get to the loop it doesn't know about it? Anything to do about that?
June 3, 2011 at 2:07 pm
Not aware of any defects in that version. Hm, mapping without a drive letter should work just fine.. Not sure why you got that particular error.
The important thing to remember is security context, I could see the drive being
"available" but only within the context that created it.. How about mapping the drive and then using the UNC to reference it instead of the drive letter. I'm just really cautious about using mapped drives where there isn't a users at the screen. I have had endless trouble with that.
CEWII
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply