tolo1984
Posts: 34
Joined: Tue Jul 26, 2011 9:47 am

enviroment variable strange behaviour

Hi,

We've a really odd issue regarding environment variables.

We have to upgrade an existing postgre database.

So in a certain point, after "Start Services", we launch a custom action -> 'Launch File'
where psql (a postgre utility to run scripts ) is launched.

We know postgre is not of your competence, but we are desperate an maybe you have any idea of whats happening.

Check this.

psql.exe needs a password for that connection. That password can be provided in a user environment variable --> PGPASSWORD.


1- We use Advanced Installer to install that environment variable ('System Changes' -> Environment )
We have checked that it is correctly set by the installer before custom action (psql) is run.
But psql acts if it doesn't exists..

but

2- We MANUALLY set PGPASSWORD environment variable before running the installer.
and everything goes right !!!!!! (psql finds it and doesn't prompt for the password)




Shouldn't be any difference, right??
It seems it is not exactly the same to set the variable manually that by the installer,
even though we do both under same user account.

we've checked nine thousand, seventy three times... desperate and thinking in suicide.

Any idea? permissions...? something...?

info:
Windows Vista.
UAC disabled
We even set WriteEnviromentStrings execution order before FileInstall,
so it is a lot of time between both actions ( environment variable .... psql run)
IMPORTANT: "Start Service" standard action is not executed. (is conditioned...)
(in a clean installation we create and run a service that we don't want to exists when 'upgrading' old version)


custom action (psql run) is "Deferred with no impersonation". (anyway it works perfectly if we create the variable manually before launching the installer...)


any help or clue ?

thank your very much
mihai.petcu
Posts: 3860
Joined: Thu Aug 05, 2010 8:01 am

Re: enviroment variable strange behaviour

Hello,
we've checked nine thousand, seventy three times... desperate and thinking in suicide.
Kill that thought, it's good you thought Advanced Installer support as well :)

I'm afraid that the system is notified of the change of the environment variables after the installation process is completed. So it doesn't matter where you place the custom action because the environment variables will not be found.

For more information on this topic please read this MSDN article.

We may have to add saving lives to our support profile description after this :wink:

All the best,
Mihai
Mihai Petcu - Advanced Installer Team
Follow us: Twitter - Facebook - YouTube
tolo1984
Posts: 34
Joined: Tue Jul 26, 2011 9:47 am

Re: enviroment variable strange behaviour

We're still here.
We recovered the will to live. ; )

Finally we used a workaround. The psql command of postgre can be passed the password by a file in a certain location.
So we solved this for the moment.

Anyway I tell you that there's something annoying with that.

Our installer, when installing on a 'clean' machine ( not previous version of our software...)
performs ok!!!

And basically made the same approach ( installing enviroment variable, the run psql to execute databse creations cripts...)

The only differences between both cases are:

1- When upgrading, "Start services" is not "executed. because we don't want to install postgre service.
2- When upgrading, we run the psql.exe already installed on the machine. (there's a reason for that...) instead of running the psql .exe shipped on the setup (that is executed on a clean installation)

And now you are thinking.... ("ey... guys maybe psql.exe versions stuff...?")

Don't think so. Remember that when upgrading, if we manually set the environment variable before launching the installer, it works ok.


Anyway, we saved the ass with the pgpass.conf file....

But maybe someday you discover something related to this.

Anyway. Thank you very much. Mihai.
mihai.petcu
Posts: 3860
Joined: Thu Aug 05, 2010 8:01 am

Re: enviroment variable strange behaviour

You're welcome, glad to assist.

This shouldn't be an upgrade dependent issue. The behavior I described in my last post is generic and shouldn't be influenced by the installation type.
However, since you brought it up, I notified the development team and they'll consider what you found.

I'll also be sure to post on this thread when their investigation proves conclusive.

Happy holidays ! :)
Mihai
Mihai Petcu - Advanced Installer Team
Follow us: Twitter - Facebook - YouTube

Return to “Common Problems”