February 11, 2014 at 12:27 pm
Hello,
I have a SQL server using a scheduled job to call a SSIS package which copies tables from one server to another. I was asked to add a few more tables to the job. So far I have opened the solution and under Control Flow there is a Transfer SQL Server Objects task. I have edited this and under tables to copy I have added the new tables and saved the solution. This has not brought over the new tables. Is there anything else I should be doing?
Thanks,
Joe
February 13, 2014 at 12:29 am
jevogelsong (2/11/2014)
Hello,I have a SQL server using a scheduled job to call a SSIS package which copies tables from one server to another. I was asked to add a few more tables to the job. So far I have opened the solution and under Control Flow there is a Transfer SQL Server Objects task. I have edited this and under tables to copy I have added the new tables and saved the solution. This has not brought over the new tables. Is there anything else I should be doing?
Thanks,
Joe
Have you deployed the package to the location which the SQL Agent job is picking it up from?
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.
February 13, 2014 at 5:38 am
It was a existing package I am trying to edit so I would assume so. Please mind any ignorance on my part I only have a minor in SQL, filling in for our real DBA. I
I first ran a import data wizard on the destination DB to bring over the new tables and that went fine. The scheduled job has 2 steps, the first is T-SQL to truncate the destination tables, which works fine (as the tables are now blank). The 2nd step is the SSIS package, which I was able to open and edit and add the new tables, but they are not populated. I did edit the job under my account and then re-opened it via the SQL agent account and it still looks fine, but I am still missing something.
Its a small package I am wondering if it is worth building a new one?
February 13, 2014 at 5:48 am
jevogelsong (2/13/2014)
It was a existing package I am trying to edit so I would assume so. Please mind any ignorance on my part I only have a minor in SQL, filling in for our real DBA. II first ran a import data wizard on the destination DB to bring over the new tables and that went fine. The scheduled job has 2 steps, the first is T-SQL to truncate the destination tables, which works fine (as the tables are now blank). The 2nd step is the SSIS package, which I was able to open and edit and add the new tables, but they are not populated. I did edit the job under my account and then re-opened it via the SQL agent account and it still looks fine, but I am still missing something.
Its a small package I am wondering if it is worth building a new one?
It is unlikely that the package you have edited is the same as that which is deployed.
Click on the package in your solution and check its 'Full Path' property.
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.
February 13, 2014 at 5:53 am
This is very possible. In the Job Properties the package is called by "\PackageName" and not a full path. I am assuming this is the default path then so I went to "C:\Program Files\Microsoft SQL Server\90\DTS\Packages" and in here there is a folder with this name and also files in the root so I am guessing the package is in 2 copies but only one location has a .dtsk file, so this is where I did my editing.
I have searched the server for additional packages with this file name and have come up blank unless there is another one by this name stored within SQL and not on the file system.
February 13, 2014 at 6:50 am
I think you got me in the right direction. The package was a SQL Server package not a file system. I used this package and saved a 2nd version to SQL which let me replace the package with my updated one which is now working.
Thanks
February 13, 2014 at 6:53 am
jevogelsong (2/13/2014)
I think you got me in the right direction. The package was a SQL Server package not a file system. I used this package and saved a 2nd version to SQL which let me replace the package with my updated one which is now working.Thanks
Great, well done!
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.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply