Brandie, thanks for the reply. I view Environment Variables as Package Configurations when talking SSIS. So all Env Vars are package configurations, not all package configurations are environment variables. Other Package Configurations are XML config files, registry entries, Parent package variables, etc, all set up in BIDS under the SSIS>Package Configurations.

Environment Variable values are set on a particular machine under System Properties>Advanced Tab>Environment Variables Button>System Variables. I think you can set them using DOS commands and I guess you could edit them directly in the registry as well.

I'm calling the package from a SQL 2005 Job, w/ an SSIS step.

The package seems to be picking up the old value of the env var. Do to unfortunate circumstances, we have to switch the values of Env Vars a lot and we found that the value we changed from persists when a package is rerun.

We aren't able to reboot the server as often as we flip this env var around, in fact its a real big event to bounce a box, even a dev box.

And it really seems to be just one particular env var, one we use to store the name of a server. When we flip it to another server name, for some reason the value @ runtime is the old value. I made a bare bones package to simply report the value of this particular env variable and another one I just created brand new. I have two global vars in my package whose default values are just random strings.

I mapped my global vars to the env vars and in the package I slap them in to a third var via a script task then email myself that third var via an email task. I deploy my package, run via a job, note the values. I then change the two env vars' values, run the package via the job, note the values. I then redeploy my package, run via the same job, note the values. Results are very weird. From the first run of the package, my one troublesome variable seems to be passing a value not equal to the value of my env variable at the time I first deployed the package. I know this value as it is one of the values we switch among, but I don't recall the last time we had the env var set to this, not in recent past, but probably since the last bounce. For each of my runs of the package, this troublesome variable remains consistent coming across as the same "old" value. The "new" variable seems to work fine, the value I change it to comes to the package correctly only after I redeploy the package.

So I guess what we're finding is that the package doesn't retrieve the value of env variables at runtime, and sometimes it doesn't retrieve it at all. It doesn't make sense, but that's what we're working off of. Its either that or env variables have their values stored somewhere that isn't updated when I think they are and a reboot is in fact needed. I talked to one of our Windows Admins and he says that the value returned for a env variable when you type "SET" in to the DOS prompt is expected to be that actual/real value of the env variable. We're just not seeing that to be true.

My next step is to request a bounce of the server and see how that impacts things. But from what I'm reading is that a bounce is not necessary.