Jezza101


Im using embedded SS2000 DTS packages in SSIS. These legacy packages use Dynamic Properties Tasks to pick up connection settings from a named ini file. The name of that ini file needs to change occasionally. To date the only way we have of doing this is resetting all the dynamic properties to point at the new ini file. Unfortuntely there are a lot of connections and properties and there is no budget to recreate these packages in SSIS. There must be an easier way !

Does anyone know how to quickly change Dynamic Properties Tasks to look at a new ini




Re: DTS old style and Dynamic Properties Tasks

Anthony Martin


Is the name/location of the ini file set through a global variable If so, simple change it to the new ini filename/location.







Re: DTS old style and Dynamic Properties Tasks

Jezza101

Thanks. No, unfortunately it is not. Would you be able to elaborate on how to set that up

In the Dynamic Properties Task, to see what value is being picked up for a given eg connection, I click through to a window entitled Add/Edit Assignment.

Source is set to INI File.

There is then the File box which allows me to enter eg c:\myconfig\myconfig.ini

Are you saying it is possible to add a variable into that box






Re: DTS old style and Dynamic Properties Tasks

Anthony Martin

You set global variables by clicking package > properties and then selecting the 'global variables' tab.

Then you refer to this variable in your dynamic properties task.

I've also seen packages that use an activeX script task to read the values for global variables from a sql server table. Unfortunely, I no longer have a code example of how to do it that way.

I guess what is the reason that name of the ini file has to change Couldn't you just change the values inside of the ini file

Also, perhaps it's time just to rewrite the packages in SSIS.






Re: DTS old style and Dynamic Properties Tasks

Jezza101

Thanks. You are right, but I am limited in options Sad.

Ultimately the brief of this project was to be as quick as possible. I'd love to rewrite them - a chance to learn new stuff! But sadly this is deemed "risky". Pah! Ironically I think we would have been better off rewriting due to issues that could easily be solved with SSIS.

The root of this is customer requirement to have a test and production setup on one server, not something we support or recommend! Personally I think we should tell them not to be so tight and get another server onto 2005 already. But again, I dont get to make the decisions...!

I think there is no "easy" way to do this. Looks like a fun couple of hours repointing dynamic property tasks.