Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2005 Forums
 SSIS and Import/Export (2005)
 Deploying to server and other questions...

Author  Topic 

igorblackbelt
Constraint Violating Yak Guru

407 Posts

Posted - 2007-07-13 : 16:23:38
Guys,
Let me first give you a little bit of background...

One of my goals for this year is to migrate all DTS packages to SSIS, those DTS packages are used across the company by different groups/users.

Since I'm still not that familiar with SSIS and like many here, was well used to the enterprise manager view (all DTS packages on 1 single place), I'm unsure on how to structure my SSIS packages in a way that I could break it down by group let's say.
The way that I'm doing right now is: I'm creating a solution for each group and creating the SSIS packages (.dtsx) relative to that group inside each solution, that's pretty easy. Now, the next thing that I'll have to figure out (and hope you guys can help) is how to deploy them structured this way and how to handle these packages to my end users. Basically, how do I handle "Group A" all of their SSIS packages? Will they have to open the package in debug mode on VS every time they need to execute a package?

Thoughts on this?

setbasedisthetruepath
Used SQL Salesman

992 Posts

Posted - 2007-07-17 : 16:29:14
In my organization we use file deployments for the SSIS packages, though users have no access. On the off chance they would need it they can execute via dtexec.exe.

Jonathan
Go to Top of Page

nr
SQLTeam MVY

12543 Posts

Posted - 2007-07-17 : 20:27:40
>> Will they have to open the package in debug mode on VS every time they need to execute a package?

No - dtexec.

Hold the packages as files.
I tend to add the file to a solution when I need to edit it then save back to the file and not save the solution. So all the files are separate and there is nothing connecting them (makes it easier for remote development).
Keep the files in sourcesafe or your version control product of choice.
Use config files to make the packages environment independant.

==========================================
Cursors are useful if you don't know sql.
DTS can be used in a similar way.
Beer is not cold and it isn't fizzy.
Go to Top of Page

igorblackbelt
Constraint Violating Yak Guru

407 Posts

Posted - 2007-07-19 : 12:13:15
Thanks for both replies, very useful information...

I think I'm in the right track, I'm keeping them as files and using DTExecUI to execute them, just not doing as Nigel's suggested on not saving the files to the solution, I'm saving everything under a specific solution. I'm also keeping the files on sourcesafe for version control. Not making use of config files yet, haven't got to that part yet.

The one thing that I was asked, and I don't know if that's going to be possible, they (upper level mgmt) want to have some type of report of all the packages executed, so we know how much data was moved from point A to point B, is it possible to get information from an SSIS package logged somewhere?

Another thing, the packages run fine on VS but are failing when executed via dtexec, it's a simple DB to File transfer. Any ideas?
Go to Top of Page
   

- Advertisement -