weirdo12

Like you, I used SQL Anywhere as the default for many, many years - starting when it was still known Watcom SQL and running on DOS. I switched to using SQLite as the default database that the product ships with because it provided the same kind of installation experience (along with maintaining SQL Anywhere support for existing customers). When a new multi-user server is required, I use PostgreSQL.

Just to be clear, are you referring to renaming controls that you drag and drop or naming ones you are creating dynamically? I missed the previous post...

You should post your final syntax to help others who encounter that same issue.

I did some quick searching about this 32-bit/64-bit client libraries and old version/new version server issue as it relates to PostgreSQL. For the record, here's what Tom Lane (core PostgreSQL developer) has to say:

In case you need the final 32-bit version of PostgreSQL to get the correct libraries, here is a link: https://get.enterprisedb.com/postgresql/postgresql-10.23-1-windows.exe

The error you show is typical of what I see if the 32-bit Visual Studio C++ Runtime is not installed. https://www.canscale.com/support/software/dispatch/docs/3.1/webhelp/dsptch31.htm?postgresql_troubleshooting.htm

The other thing to remember is that you need to have the 32-bit version of the Visual Studio run-time library installed or the 32-bit PostgreSQL libraries won't work. https://learn.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist?view=msvc-170#visual-studio-2013-vc-120

I found that the library files had to be in a sub-directory named lib but that may have changed since I originally started supporting PostgreSQL. I use 12.2 now and just put the files in Debug\lib and Release\lib out of habit.

I mentioned this in another thread. It may help. I don't open database or edit queries in the IDE so it may not.

In my experience, putting libpg.dll and its dependencies in debug\lib and release\lib works and eliminates having to specify a folder in the driver componenent.

So just to extend the conversation as it pertains to the original code, there is no need to store TBitmapLayer* at all (except for convenience as a temporary so that it can be initialized as required). The best practice is to always access a layer through ImageBackground->Layers->Items. Would that be good advice or overkill?

Another approach is to use std::vector<std::unique_ptr<TBitmapLayer>> created by std::make_unique instead of using an array of raw TBitmapLayer pointers which can lead to memory unsafe code. When the std::vector is destroyed (goes out of scope) everything gets cleaned up.

There isn't a property or global setting that will do that.

Right click on the source file and choose Edit local options.

What is the data type of field1? Can you share the schema of the config table?