September 29, 2016 at 1:48 pm
Hello,
I have an existing solution that that populates a cube. It's on the local C:\ of the server, and I need to copy it to a share drive that is on another partition on the server.
I opened the solution, I can see all the related packages that are involved, and I did a Save....As, and copied it to the share Drive. I nav to that share, and it created only a .sln file and a dir, I open it and it's basically empty.
I go back and look at the original folder it was in, and it seems to have added an extra subfolder where the main content is now, but as a second layer, and the first folder is much like the empty file that got copied to the share drive.
I'm concerned that this is going to fail the job that looks for that dir tomorrow when it runs, but ... how do I successfully copy all the content of an existing solution to another share, everything remain intact, and presumably all the file paths, etc within the solution will remain pointed to source/target properly. I need to modify this solution as a one-off.
Thanks
September 29, 2016 at 2:52 pm
The solution files are only needed for development. Once you've built the package into it's .dtsx file, the solution is really not needed. Your job is not calling the solution, it's referencing the .dstx file. So just move the .dtsx file over to the new location and make sure the job step references it there. I'm assuming from your post that your jobs are referencing file system packages and not packages in the catalog.
September 29, 2016 at 3:07 pm
John Rowan (9/29/2016)
The solution files are only needed for development. Once you've built the package into it's .dtsx file, the solution is really not needed. Your job is not calling the solution, it's referencing the .dstx file. So just move the .dtsx file over to the new location and make sure the job step references it there. I'm assuming from your post that your jobs are referencing file system packages and not packages in the catalog.
Hi John, I think your right, I was expecting it to copy the whole lot, but it didn't. So I ended up using File Explorer, and copied the whole project folder to the share drive. then I opened VS, nav to the share, opened the main file, all was there. So I went through turning off the encryption on each of the .dstx packages. All was going well, until, I renamed the package name, then, every single package became "lost" as now there is no content.
So clearly, it's not so easy to copy an existing solution lock stock and barrel, remain intact, rename it, and plunk it into another location. I want to make a renamed copy of an existing solution over to another share drive, so I can make mod's to it, and not loose paths, pointers, etc... is there a step-by-step for this task?
September 30, 2016 at 6:27 am
Again, I'm not sure why you think you need to move a solution. All you need are the .dtsx files. Move those to a network location where you can see them from your SQL Agent jobs. If you need to open them in a solution for editing, create a new project in Visual Studios, start a blank project, right-click on the SSIS Packages folder in the Solution Explorer, and select 'Add Existing Package'. Then you have them in your solution for editing.
There needs to be a clear line drawn between package development and package execution for you. Visual Studios is used for package development, but not needed for run-time operation of your packages. In fact, if you are setting up your SQL Agent to execute packages from the file system, you do not ever want to refer to a package that is embedded in the solution folder structure. Develop the package, build it into .dtsx file, then move the .dtsx file to the target folder where you have your SQL Agent running them from a job step. Make sense?
September 30, 2016 at 6:34 am
quinn.jay (9/29/2016)
John Rowan (9/29/2016)
The solution files are only needed for development. Once you've built the package into it's .dtsx file, the solution is really not needed. Your job is not calling the solution, it's referencing the .dstx file. So just move the .dtsx file over to the new location and make sure the job step references it there. I'm assuming from your post that your jobs are referencing file system packages and not packages in the catalog.Hi John, I think your right, I was expecting it to copy the whole lot, but it didn't. So I ended up using File Explorer, and copied the whole project folder to the share drive. then I opened VS, nav to the share, opened the main file, all was there. So I went through turning off the encryption on each of the .dstx packages. All was going well, until, I renamed the package name, then, every single package became "lost" as now there is no content.
So clearly, it's not so easy to copy an existing solution lock stock and barrel, remain intact, rename it, and plunk it into another location. I want to make a renamed copy of an existing solution over to another share drive, so I can make mod's to it, and not loose paths, pointers, etc... is there a step-by-step for this task?
Renaming of packages can be done within Solution Explorer ... the list of packages in a project is held in the project file, which gets updated if you perform the rename this way.
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.
September 30, 2016 at 9:15 am
John Rowan (9/30/2016)
All you need are the .dtsx files. If you need to open them in a solution for editing, create a new project in Visual Studios, start a blank project, right-click on the SSIS Packages folder in the Solution Explorer, and select 'Add Existing Package'. Then you have them in your solution for editing.
Thanks, this helps. So as I learn, the next price I have to understand that you said was to place it where it is viewable by the Server Agent, and I'm not so sure what or how to assure that. I'm going to copy the .dtsx files to the share drive and step through what you outlined.
September 30, 2016 at 9:53 am
quinn.jay (9/30/2016)
John Rowan (9/30/2016)
All you need are the .dtsx files. If you need to open them in a solution for editing, create a new project in Visual Studios, start a blank project, right-click on the SSIS Packages folder in the Solution Explorer, and select 'Add Existing Package'. Then you have them in your solution for editing.Thanks, this helps. So as I learn, the next price I have to understand that you said was to place it where it is viewable by the Server Agent, and I'm not so sure what or how to assure that. I'm going to copy the .dtsx files to the share drive and step through what you outlined.
If you are on a recent version of SSIS, this is not necessarily true. Instead, packages can (and, I would argue, should) be grouped into projects in VS and then deployed to SSISDB. Setting up a SQL Agent job to run packages deployed this way is trivial.
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.
September 30, 2016 at 10:07 am
Phil Parkin (9/30/2016)
quinn.jay (9/30/2016)
John Rowan (9/30/2016)
All you need are the .dtsx files. If you need to open them in a solution for editing, create a new project in Visual Studios, start a blank project, right-click on the SSIS Packages folder in the Solution Explorer, and select 'Add Existing Package'. Then you have them in your solution for editing.Thanks, this helps. So as I learn, the next price I have to understand that you said was to place it where it is viewable by the Server Agent, and I'm not so sure what or how to assure that. I'm going to copy the .dtsx files to the share drive and step through what you outlined.
If you are on a recent version of SSIS, this is not necessarily true. Instead, packages can (and, I would argue, should) be grouped into projects in VS and then deployed to SSISDB. Setting up a SQL Agent job to run packages deployed this way is trivial.
Yes, this is absolutely true for project deployment, but it seemed from the OP's original post that this was all file system deployment. This does bring up the point that maybe he should completely reconsider their package deployment strategy and get away from file system deployment. Google SQL Server SSIS Deployment Model and you'll get a bunch of info that could help you make your decision.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply