October 11, 2017 at 11:45 am
Hi,
Within a Foreach loop, I have a simple Script Task to check if a file exists. If it exists, then FTP the file. If does not exist, then add the full file path to a error log table.
The script -
If (File.Exists(Dts.Variables("User::strFullPath").Value.ToString())) Then
Dts.Variables("User::bolFileExists").Value = True
Else
Dts.Variables("User::bolFileExists").Value = False
End If
My test data has 6 files to find, of which only 4 exist.
In Visual Studio, this runs fine and FTP's 4 files and writes 2 entries to the error log.
However when Deployed to SQL Server 2016, the project runs OK, but fails to find any files. So all 6 entries get written to the error log.
Everything is on my laptop.
I've tried with local path names (C:\PathName\FileName.jpg) and UNC names (\\LAPTOP\ShareName\FileName.jpg).
Both the source Folder and Share have been given Read permission to Everyone.
In Visual Studio, I've set a break point on the Foreach loop and verified that the "strFullPath" variable is passing a valid path/filename - although at this level it does have additional "\". So \\LAPTOP\ShareName\FileName.jpg becomes \\\\LAPTOP\\ShareName\\FileName.jpg
Any idea why I'm missing that is stopping this working correctly when Deployed?
Many thanks
Tim
Tim
October 11, 2017 at 12:00 pm
Tim Pain - Wednesday, October 11, 2017 11:45 AMHi,Within a Foreach loop, I have a simple Script Task to check if a file exists. If it exists, then FTP the file. If does not exist, then add the full file path to a error log table.
The script -
If (File.Exists(Dts.Variables("User::strFullPath").Value.ToString())) Then
Dts.Variables("User::bolFileExists").Value = True
Else
Dts.Variables("User::bolFileExists").Value = False
End IfMy test data has 6 files to find, of which only 4 exist.
In Visual Studio, this runs fine and FTP's 4 files and writes 2 entries to the error log.
However when Deployed to SQL Server 2016, the project runs OK, but fails to find any files. So all 6 entries get written to the error log.
Everything is on my laptop.
I've tried with local path names (C:\PathName\FileName.jpg) and UNC names (\\LAPTOP\ShareName\FileName.jpg).
Both the source Folder and Share have been given Read permission to Everyone.
In Visual Studio, I've set a break point on the Foreach loop and verified that the "strFullPath" variable is passing a valid path/filename - although at this level it does have additional "\". So \\LAPTOP\ShareName\FileName.jpg becomes \\\\LAPTOP\\ShareName\\FileName.jpgAny idea why I'm missing that is stopping this working correctly when Deployed?
Many thanks
Tim
Are you deploying to the SSIS Catalog on your laptop, or to a server somewhere?
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
October 11, 2017 at 1:03 pm
To SQL running on my own laptop.
So at present, everything is on my laptop.
Thanks
Tim
October 11, 2017 at 1:28 pm
Tim Pain - Wednesday, October 11, 2017 1:03 PMTo SQL running on my own laptop.
So at present, everything is on my laptop.Thanks
OK. If you compare the All Executions report for a run which completes as expected with one which does not, do you see any unexpected differences or anomalies?
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
October 11, 2017 at 2:03 pm
Thom,
Permissions was my though as well, hence the Read permission for Everyone on the folder with the *.jpg files. Which is overkill, but in my mind should eliminate any Permissions issues?
Phil,
I've tried
I could run it from the Agent for testing, but when I get it working and go to production, I plan to use the EXEC SSIDB.catalog option.
Both report Success in the All Executions report. Both show the Script Task being run. And bot then end up with 6 records in the error log saying that the image files were not found.
Thanks
Tim
October 12, 2017 at 9:28 am
Sorry for late reply.
If you're using T-SQL to run the task, however, then I'm pretty confident that the problem is our old friend "Mr Double-hop" (Phil, would you agree?). This is a kerboros related issue, and you need to allow multiple jumps via it. What is (likely) happening at the moment is that the access to the directory is being made anonymously (and thus denied).
You'll need to speak to your Network Administrator on enabling authentication via "double hopping". They should be aware of what it is, and how configure it correctly.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
October 12, 2017 at 10:42 am
Thom A - Thursday, October 12, 2017 9:28 AMSorry for late reply.If you're using T-SQL to run the task, however, then I'm pretty confident that the problem is our old friend "Mr Double-hop" (Phil, would you agree?). This is a kerboros related issue, and you need to allow multiple jumps via it. What is (likely) happening at the moment is that the access to the directory is being made anonymously (and thus denied).
You'll need to speak to your Network Administrator on enabling authentication via "double hopping". They should be aware of what it is, and how configure it correctly.
I've had Kerberos issues in the past when attempting to execute packages directly from SSMS, yes. But running in SQL Agent has always been pretty reliable, whether executing packages directly, or via a stored proc (which does the usual Catalog.CreateExecution stuff).
What puzzles me is that this is all happening locally, so nothing should be getting in the way. The Network Admin is probably not the guy to turn to with this one!
Question for the OP: In the All Executions report, under 'All Messages', what appears under 'Caller'?
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
October 12, 2017 at 10:45 am
Thom,
Thanks for your input. Its maybe sort of confirmed by the report All Executions - Overview, showing CALLER_INFO as blank.
Although, I've also found that if I set up an Agent job and run it from that, then CALLER_INFO is set to SQLAGENT, but it still does not work.
I'm still working through it, but if I deploy the package to the File System and then execute that, via DTEXEC, so far it seems to work as expected. Its not quite what I wanted, but it's something I can certainly live with.
Thanks
Tim
October 12, 2017 at 10:50 am
Tim Pain - Thursday, October 12, 2017 10:45 AMThom,Thanks for your input. Its maybe sort of confirmed by the report All Executions - Overview, showing CALLER_INFO as blank.
Although, I've also found that if I set up an Agent job and run it from that, then CALLER_INFO is set to SQLAGENT, but it still does not work.I'm still working through it, but if I deploy the package to the File System and then execute that, via DTEXEC, so far it seems to work as expected. Its not quite what I wanted, but it's something I can certainly live with.
Thanks
But what about Caller? CALLER_INFO appears to be blank for me too, so that's probably a red herring.
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
October 12, 2017 at 10:50 am
Phil,
As mentioned above, if its called via the Agent, then SQLAGENT.
It's is called directly or via the Catalog.Create stuff, then CALLER_INFO is blank.
Thanks
Tim
October 12, 2017 at 10:54 am
Sorry, misread what you had asked.
Caller is me "MicrosoftAccount\MyName@gmail.com"
Tim
October 12, 2017 at 10:58 am
Tim Pain - Thursday, October 12, 2017 10:54 AMSorry, misread what you had asked.
Caller is me "MicrosoftAccount\MyName@gmail.com"
Is that account a local admin?
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
October 12, 2017 at 11:13 am
Sorry, I hadn't noticed that this was all being run locally, so no, network guy is the wrong person.
If, however, the OP can use DTExec to do it, this still likely points to Kerboros Double hop. Even if you are running locally (SSMS on the same Machine as the SQL Instance, which, in turn is the same machine the file is on) the double hop issue will still arise. The credentials are still going SSMS->SQL Server->File System, it doesn't matter if it's all the same server, at the point of SQL Server-> File System you're at the point of the "double hop". I would put money on betting that if the OP tried to execute the task via Agent it would also work.
I'm not going to lie, I have no idea on how to resolve the matter of the double hop. Sorry (I realise not being helpful there). I am, however, intrigued to hear if it does work via Agent (as I suspect).
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
October 12, 2017 at 12:15 pm
Phil - Yes the account is local admin
Thom - Everything is on the laptop, so I should be able to kill the WiFi connection and it should still run.
Using the Agent, I get the same results as executing the Package i.e.: It runs without errors, but fails to find any of the 6 files and then outputs 6 records to the error log.
Thanks
Tim
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply