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