Re: [EXTERNAL] Re: BUG #18707: Installation issue
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>
Cc: PANESAR Gursharan <gursharan.panesar@bnpparibas.com>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Date: 2024-11-20T22:41:29Z
Lists: pgsql-bugs
On Wed, Nov 20, 2024 at 12:15 PM Thomas Munro <thomas.munro@gmail.com> wrote: > Idea: could the Visual Basic program actually be using a different > ACP, not the one in the registry, due to some explicit locale setting > or environment variable somewhere? Would it be better to call > GetACP() instead of that registry lookup[2]? Guessing harder, in more actionable form: something like LANG="fr-FR.UTF-8" might be enough to break your script, if VB itself or something in your VB code calls setlocale(LC_ALL, ""). I have no idea if it does, but if so, that could change the ACP for the process, I think. Perhaps Gursharan might like to check whether LANG or any of the LC_ is set in the environment where the installer runs, and if so whether the value implies a codepage that doesn't match HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\ACP. If so, just as an experiment, changing the variable to something with a matching codepage (I think for example "fr-FR" without suffix implies 1252, traditional encoding used for French) might work, just to confirm what's happening, or kill this theory :-) And if that's it, and if GetACP() is the solution, then: the intergoogles told me that you should be able to 'Declare Function GetACP Lib "kernel32" () As Long' to access it.