Path of INI file
-
I am reading the INI file in many packages for variables, file paths etc. But the Path of the INI file is hardcoded in each package. How can I make the path of the ini file dynamic so that the packages can be moved from one server to another without problems.
The current development environment has the ini file in "E" drive. What happens if the production environment does not have the E drive?
Thanks!
-
always better to keep ini file at he place where exe file is there or in some folder so if you are using any front end application like vb then you can get path like
app.path &"\file.ini"
or other better way to keep file in wondows folder. using api you can find out what is path of windows folder
-
If you are talking about DTSs in particular did you know you can pass in parameters to a DTS when called from a command line? Look up the dtsRun utility in BOL.
That way you can pass in the INI file location as a global variable.
"Don`t try to engage my enthusiasm, I don`t have one."(Marvin)
-
thanks for the reply, but how will I build the global variable? Will I not have to hardcode the value of the global variable in the code, or read it from a data file? where will I store the path of the data file?
I can read it from a table...where will I read the conection information from...this information is in the INI file.
-
If the INI file is always in the same location relative to the application calling it then ajays suggestion makes sense.
If you do store the path in a table then, from a DTS, that is even easier, just put the SQL to get the path from the table in an execute SQL task, click on 'Parameters' then select the 'Output Parameters' tab and select the Global variable you want to put the path into.
Once its in a global variable you can use it as an input parameter to SQL tasks, or use it in VB Script tasks, or change the properties of a connection or task using the dynamic properties task etc etc
"Don`t try to engage my enthusiasm, I don`t have one."(Marvin)
-
>>If you do store the path in a table then, from a DTS, that is even easier
This is the crux of the whole DTS catch-22 configuration issue.
You can`t read a table in DTS without a connection.
You don`t want your connection to be hard-linked to a certain server, otherwise you can`t move packages from DEV to QA to Production.
So you want your connections to be configurable, and you`d like your configuration to be table driven, but you can`t read the configuring table without the data it contains to configure the connection. Cue headache and bulk Advil purchase.
Hence the question, what happens if you use an INI file and are suddenly presented with a server that doesn`t have a certain drive or path ...
-
We appear to be going around in circles
Look, in any installation you have to have some point at which you set up the paths/DB names etc, this is true of any application, not just DTSs (thats what a setup.exe installation file does, it asks you where you want to put the application, then sets a bunch of registry settings that point to it).
And like any other app there are many ways of getting this info into the DTS, its up to you, you can run the DTS from a command line and have the connection name/Login etc passed in as parameters, you can put them in the registry and read them back with a VB script, you could put them in an INI file in the path to make it universally available, you can have the DTS pop up an inputbox for the user to enter the details or you could simply spend 2 minutes changing the connection details in DTS designer. Actually you could even create a setup.exe for it.
The point is you will have to enter these details somewhere.
One other thought - you could try using the 'Local' DB name, then you should just need a consistent Login and Password on all the servers (untested!
)
"Don`t try to engage my enthusiasm, I don`t have one."(Marvin)
-
As you have quite rightly pointed out it is a problem.
The only way I have been able to do it is use the DTS Object Model to amend the ini file path in an ActiveX script before the DP task runs.
Yes, this needs to be hard coded, but the adv is only in ONE place with one single reference. This overcomes the problem that you have pointed out of if you have multiple references to the .ini file in the DP task that would need to be amended when eg moving a dts package where the reference to the .ini file changes.
Not an ideal solution I know, but I now only have to amend one line, rather than change all references to the .ini file in the DP task.
PRW.
Paul R Williams.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply