October 21, 2009 at 2:45 pm
I have a file system SSIS package (SourceFolder\GLload.dtsx). Jobs executes this package as SQL Server Integration Services Package and picks package from above path and it runs successfully.
Now GLload.dtsx is modified and copied the modified .dtsx file to SourceFolder\GLload.dtsx. The job executes the previous package and not the modfied package.
From where it is getting the older package and why the job is not picking up the new package?
Appreciate your help on this. Thanks!
October 22, 2009 at 7:16 am
I would suggest to delete the present job and create a new one.
This should resolve the problem.
Pankaj
October 22, 2009 at 7:59 am
Thanks for your suggestion.
But why do we need delete and create the job again? Even though package is modified,but the path of the .dtsx file is same. Why can't the job command is unable to execute the latest one?
Any other alternate solutions please.
Your inputs are greatly appreciated.
October 22, 2009 at 2:03 pm
Are you 100% certain that the latest version of your package was actually deployed to that folder?
October 22, 2009 at 2:33 pm
Yes. If I renamed the same file and execute the renamed file from Job, it executes perfectly with modified changes in the package.
If I copy the updated file and replace the existing one in the folder path,then the job will not pick the latest file, instead it will run the older version. Not sure from where it is getting the older version even though the path contains the latest file with changes.
October 22, 2009 at 9:01 pm
Have you deployed the package in SQL Server or it is in File System?
Whatever it is currently, try changing to the other one.
Blog -- LearnSQLWithBru
Join on Facebook Page Facebook.comLearnSQLWithBru
Twitter -- BruMedishetty
October 23, 2009 at 1:05 am
Please post the command line which executes the job.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
October 23, 2009 at 3:09 pm
Package is file system object. No I can't change it to SQL server as it production and we follow file system standards.
Package is executed as a Job.
Job Name: Exec SSIS
Type: SQL Server Intergration Package
Package Source: File System
Package: \\serveraname\foldername\GLLoad.dtsx
October 24, 2009 at 4:10 pm
First of all, there's no such thing as magic or ghosts, not even for SSIS package files. The old package file is still whereever the job is told to get it. The last post showed what appears to be a resource name for the location of the dtsx file. It is possible that what is shown as "foldername" is actually a shared resource on the server that is actually named something else?
For instance, let's imagine a server with folders named "OldDTSX", "RunDTSX" and "DTSX". Folder "RunDTSX" could be shared with a share name of "DTSX". The old version of the package file may have been put into folder "DTSX" and then copied to folder "RunDTSX" from which it runs today. When we put our modified package file into folder "DTSX", it doesn't affect what's run at all.
Obviously, this is speculation, but if the old code is running from a file, that file must be out there somewhere.
October 29, 2009 at 8:24 am
Thanks for reply. If I refresh the path of the file in the Job step then it picks the updated package.
October 29, 2009 at 9:27 am
venkatramreddy (10/29/2009)
Thanks for reply. If I refresh the path of the file in the Job step then it picks the updated package.
:unsure: How disappointing. I still think magic and ghosts are involved :w00t:
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
October 29, 2009 at 1:09 pm
Phil Parkin (10/29/2009)
venkatramreddy (10/29/2009)
Thanks for reply. If I refresh the path of the file in the Job step then it picks the updated package.:unsure: How disappointing. I still think magic and ghosts are involved :w00t:
If computers can have zombies running, then why not ghosts?
But, seriously, what really happened here? If the new version of the dtsx file replaced the old one by using the same name in the same directory, yet the old logic got executed, does that mean that it was somehow cached by SQL Server?
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply