Leaderboard

Had time to test it and using 32-bit client binaries from a newer PostgreSQL 32-bit ODBC driver version still works. Tested in a Windows Sandbox with a Delphi test app + binaries from the psqlodbc_15_00_0000-x86 32-bit ODBC driver with postgresql-15.13-3-windows-x64 installed. Test app is just a button that opens a connection and pulls results into a grid. Note clients / client libraries are backwards compatible except for some really old versions. You can use the client binaries from the latest release ODBC driver. Tested this with client binaries from the REL-17_00_0006 32-bit ODBC client and connecting to the 15.13-3 server mentioned above.

You need the PostgreSQL 32-bit library files and that means you should install PostgreSQL 10.23. You can still get it here: https://get.enterprisedb.com/postgresql/postgresql-10.23-1-windows.exe These are the files you will need to copy from C:\Program Files (x86)\PostgreSQL\10\bin to the same directory as your exe: libssl-1_1.dll libcrypto-1_1.dll libiconv-2.dll libintl-8.dll libpq.dll And you also need correct version of Microsoft Visual Studio 2013 (VC++ 12.0) C++ Redistributable run-time library. You can download it here: https://aka.ms/highdpimfc2013x86enu

What you are asking for can't be done if you use static linking. You would have to modify the system PATH in order to find the secondary DLLs that libheif.dll uses. You need to load libheif.dll dynamically at runtime instead. You can either rewrite your code to load libheif's function(s) explicitly via manual calls to LoadLibrary()+GetProcAddress(), or you can simply mark the functions as delayed to let the RTL handle the loading for you. But either way, this will allow you to call SetDllDirectory() or AddDllDirectory() at runtime before you call any of libheif's functions for the first time.

Dynamic loading might solve the problem. In that case you can change the current folder to be the folder where are your dlls. You can also try to use https://learn.microsoft.com/en-us/windows/win32/api/Winbase/nf-winbase-setdlldirectorya .

Not actively using PostgreSQL currently but for past use: The PostgreSQL ODBC driver comes in 32-bit and 64-bit versions and uses libpq.dll to connect. It places all the needed files in it's install directories including those it needs form the Microsoft C Runtime Library. Get the ODBC drivers from : https://www.postgresql.org/ftp/odbc/ For version 15 32-bit only that looks like it would be psqlodbc_15_00_0000-x86.zip from https://www.postgresql.org/ftp/odbc/versions.old/msi/ What I would normally do is download the ODBC installer, open a Windows Sandbox, copy and run the installer there. Then look in the appropriate Program Files directory and grab all the needed DLLs from where the ODBC driver was installed.

According to a google search that dll can have dependencies. In order to load successfully any dll you have to make sure that all the dependencies can be loaded. (You can try to find out all the dependencies using the proccess monitor). Dependencies: libpq.dll often depends on other DLLs, such as ssleay32.dll and libeay32.dll (for SSL/TLS encryption), and potentially others like libintl-9.dll (for internationalization). Open ssl can be also compiled to be dependent on Microsoft Visual C++ Redistributable runtime libraries.

In a VCL TMemo, if you try to read from a line index that doesn't exist then the output string will be blank, and if you try to write to a line index that doesn't exist then the input string will be ignored. No errors are raised. So, in your case, for example, if you try to write to Memo1.Lines[2] when Memo1 does not have at least 3 lines, then your LblLastName.Caption string will be ignored. So, like Brian said, you have to make sure a given line actually exists before you can read/write it. That being said, using a TMemo probably isn't the best choice for this task to begin with. Why not use 3 TEdit's instead? Or maybe a TStringGrid, or a TValueListEditor, or an editable TListView instead? There are many choices, depending on your UI needs.

canvas = [[' ' for _ in range(WIDTH)] for _ in range(HEIGHT)] needs to be canvas = [[' ' for _ in range(WIDTH.Value)] for _ in range(HEIGHT.Value)]

Probably the biggest problem is the inability to be precise in the statement of your issue

Great! This is a very long awaited addition for me. I hope they also add a case statement for string types