Monday, March 19, 2012

"standard packages" - where to store? Hints needed

Hi,

I would like to implement a kind of standard packages which can be used in all other processes and will be started using the variables.

But I do not know where to store these kind of packages in "best practise", because we

- would like to use them in Dev and in "Real" also without having to change something in the other processes

- we are storing the packages in the folders of the package store

and as far as I understood I would have to share the package store to all developers though that they would be able to do this?

Then I would better choose another folder with defined access rights I think...

Or would it be better to spend some time in developing a custom component?
But this component would work with recordsets rather than the standard data flow elemtents and therefor I would expect a leak of performance...
Or is it possible to do "trasnformation" from a packae to a custom component?

Thanks in advice!

cheers,
Markus

Personally, I think the best way all around is to store the common packages in SQL Server.

Unless you have a specific and valid reason to do otherwise, this is the best way because it handles a lot of the problems nicely like distribution, security and scheduling etc.

I don't understand how the latter questions relate to the common location question, sorry.

K

|||

i agree that sql server is the best place to store packages because it provides better security than the file system.

i believe that developer access should be controlled by a software configuration management system like visual studio team system.

No comments:

Post a Comment