Re: [EXTERNAL] Re: BUG #18707: Installation issue
От | Thomas Munro |
---|---|
Тема | Re: [EXTERNAL] Re: BUG #18707: Installation issue |
Дата | |
Msg-id | CA+hUKGL3W_nXk0Si9P=smGq5NHUxu4HASJwZ+gq80SHMF0tWpg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [EXTERNAL] Re: BUG #18707: Installation issue (Thomas Munro <thomas.munro@gmail.com>) |
Список | 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.
В списке pgsql-bugs по дате отправления: