Re: Patch for EDB binary path not set by default. - Mailing list pgadmin-hackers
From | Dave Page |
---|---|
Subject | Re: Patch for EDB binary path not set by default. |
Date | |
Msg-id | CA+OCxown3B-o1-82L-E4S2CoFbdt_rTUfdmT9J_ZB_O=yd_9ig@mail.gmail.com Whole thread Raw |
In response to | Re: Patch for EDB binary path not set by default. (Dinesh Kumar <dinesh.kumar@enterprisedb.com>) |
Responses |
Re: Patch for EDB binary path not set by default.
(Ashesh Vashi <ashesh.vashi@enterprisedb.com>)
|
List | pgadmin-hackers |
Ashesh - can you review/commit this please? I'm swamped at the moment. Thanks. On Mon, Oct 14, 2013 at 10:13 AM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote: > Hi Dave, > > Thanks for your valuable inputs. > > On Fri, Oct 11, 2013 at 7:05 PM, Dave Page <dpage@pgadmin.org> wrote: >> >> Hi >> >> >> On Wed, Oct 9, 2013 at 2:12 PM, Dinesh Kumar >> <dinesh.kumar@enterprisedb.com> wrote: >>> >>> Hi Dave/Team, >>> >>> When we install a 32-bit pgAdmin-III in a windows 64-bit machine, which >>> is already having the 64-bit EnterpriseDB database installed, then EDB >>> binary path not set to by default. >>> >>> Further to my observation, below is the mechanism how the pgAdmin looks >>> for the PPAS binary path. >>> >>> A) Read the settings.ini for the entry "EnterpriseDBPath" and get the >>> value. >>> >>> B) Read the "EnterpriseDBPath" as a key in the registries. If the key is >>> not found, then create one key and assign the value of settings.ini file. >>> >>> C) If the registry is found, and still the value of "EnterpriseDBPath" is >>> null, then we are checking the %PATH% which will be having the "pg_dump.exe" >>> file and it's a type of "EnterpriseDB". >>> >>> D) If we don't find any "pg_dump.exe" edb version, then we go for the >>> default locations to search for the edb version. >>> >>> I have verified the above A, B and C cases, and those are working fine in >>> a 64-bit machine. But the case D is not working as expected in a 64-bit >>> machine. Hence, would like to submit a patch for this case. >>> >>> Kindly let me know your inputs on this patch. >> >> >> I don't think you can do it that way - what if the directory name doesn't >> end in "(x86)"? You can configure Windows to use any arbitrary directory for >> the Program Files folders. I suspect you'll need to use a preprocessor macro >> to handle the 32 vs. 64 bit cases accordingly. > > Sorry for the delay on this issue. > > I have done some google around the same problem, and found the solution to > use "programw6432" environment variable , if a 32 bit application runs in a > 64 bit machine. But, this option only works on windows 7 and windows 2008 R2 > onwards. And after spending some time, i have found one suitable solution > for this case, which we need to read the key "ProgramFilesDir" from the > registry "HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion", > and i have implemented this mechanism using pgRegKey. > > Here i have used, "wxIsPlatform64Bit()" as an alternative to preprocessor > macros. > > Kindly let me know your inputs on this patch. > > Thanks in advance. > > Regards, > Dinesh >> >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company > > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgadmin-hackers by date: