October 12, 2017 at 2:16 pm
Create another package to do nothing but list the files in that directory into a table and see what happens. That might make it more clear as to where the problem comes from.
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
October 16, 2017 at 2:25 am
Steve, thanks for your suggestion.
One thing I have noticed in Visual Studio 2015, is that the Script Task seems to occasionally loose its settings and reverts to Visual C#, the Read Only and ReadWrite variables and the custom code disappear. So I do wonder if this is also happening when the project gets deployed? As during deployment, sometimes it does complain about Script Tasks and mismatching versions. I'm using VS 2015 with SQL Server Data Tools 14.0.61707.300 and deploying to SQL 2016.
So my workaround, is to do away with the Script Task and on the ForEach loop and the FTP task within the loop, set the MaximumError Count to 0 and then attach the creation of the Error Log of missing files to the Failure output of the FTP task. This seems to work with my test data, with 4 image files being FTPed and 2 image file errors (missing) being written to the error log - which is exactly what I'm expecting.
So unless somebody has got a brilliant suggestion, I can live with what I've now got.
Many thanks for you help and suggestions
Tim
October 16, 2017 at 5:54 am
Tim Pain - Monday, October 16, 2017 2:25 AMSteve, thanks for your suggestion.One thing I have noticed in Visual Studio 2015, is that the Script Task seems to occasionally loose its settings and reverts to Visual C#, the Read Only and ReadWrite variables and the custom code disappear. So I do wonder if this is also happening when the project gets deployed? As during deployment, sometimes it does complain about Script Tasks and mismatching versions. I'm using VS 2015 with SQL Server Data Tools 14.0.61707.300 and deploying to SQL 2016.
So my workaround, is to do away with the Script Task and on the ForEach loop and the FTP task within the loop, set the MaximumError Count to 0 and then attach the creation of the Error Log of missing files to the Failure output of the FTP task. This seems to work with my test data, with 4 image files being FTPed and 2 image file errors (missing) being written to the error log - which is exactly what I'm expecting.
So unless somebody has got a brilliant suggestion, I can live with what I've now got.
Many thanks for you help and suggestions
I am using the same SSDT and SQL Server versions as you. And only last week, I experienced the 'disappearing script task' problem you appear to be describing. Twice, with the same script (which, luckily, I was able to recover from source control). It seems that, under certain circumstances, the script task 'initialises' itself. So far, this has happened only during development, not deployment.
Regarding your comment about mismatched versions of script tasks during deployment, I have not seen that. Are you able to post the exact text of the message you are seeing?
One idea I might try would be to write a logging row to a SQL table somewhere, both at the start and then at the end of your script, just to confirm that it is being executed.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
October 16, 2017 at 10:47 am
For me the 'disappearing script' is a nuisance, but not big deal, as I only have one Import and now only one line of code. But in other circumstances, it could be a real pain.
As suggested, I added some code to create a log entry at the start and finish of Script code sections. And again hit the issue of deploying it and then the version mismatch.
So I re-installed the SSDT tools into VS and checked I was still deploying to SQL Server 2016 and re-deployed the package.
Now everything seems to be working exactly as expected.
Tim
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply