weirdo12

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?

Just in case you want a list of the available ODBC drivers, you can do something simple like dropping a TFDPhysODBCDriverLink component on your TDataModule and call TFDPhysODBCDriverLink.GetDrivers,

Check out their documentation or contact them directly but my understanding is they don't use the client DLL's at all.

Use Devart's MyDAC:

If you're using TClientDataSet for some serious work, I would think you should own this: http://www.jensendatasystems.com/cdsbook2/ I don't use TClientDataSet.

If you are building a stand alone app that relies on a database, why aren't you using SQLite? We used to use SQL Anywhere as our default database. It was great. The database could be one file that you could copy and move very easily. Like SQLite. But it did have an engine to install which could be done easily with InnoSetup without a separate exe included in the setup file (think SQL Server whatever). We did have have to pay for each install which was fine. But then it was sold to SAP and you know what, they just stopped asking us for royalties. I guess it was so small time they couldn't be bothered. So like 6-7 years ago I thought I'd see if I could use SQLite as a replacement. And it was possible. Obviously the database would work. The issue was with stuff stuff that was done in database - triggers - that we used and could they be done in SQLite. They could be.

Calling it with TFDBatchMove.GuesFormat is the same as calling it like this: TFDBatchMove.GuessFormat([taDelimSep, taHeader, taFields]). By default, the procedure is called will all of the analyze options. procedure GuessFormat(AAnalyze: TFDBatchMoveAnalyze = [taDelimSep, taHeader, taFields]) And after calling TFDBatchMove.GuessFormat with no arguments, the TFDBatchMove.Analyze property will has all those values - taDelimSep, taHeader, taFields. If it didn't have any default argument values it would be declared like this: procedure GuessFormat(AAnalyze: TFDBatchMoveAnalyze) https://docwiki.embarcadero.com/RADStudio/Sydney/en/Parameters_(Delphi)#Default_Parameters So if you call TFDBatchMove.GuessFormat and the don't clear TFDBatchMove.Analyze prior to calling TFDBatchMove.Execute, TFDBatchMove.GuessFormat is called again using the values from TFDBatchMove.Analyze, undoing any changes you might have made to the field types after the first call to TFDBatchMove.GuessFormat.

My Delphi cannot be trusted! I'm sure someone can suggest the correct code.

I actually missed something important: before you call TFDBatchMove.Execute call TFDBatchMove.Analyze.Clear or your changes might be overwritten. From the docs: "When the Analyze property value is not empty, then the batch move component tries to automatically recognize the data source format by calling the GuessFormat() method as part of the Execute method call." Something else I discovered last week is that WriteValue is triggered twice for any field that is part of a primary key. https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-2064

Here's an example: void __fastcall TDMImportExport::FDBatchMoveImportWriteValue(TObject *ASender, TFDBatchMoveMappingItem *AItem, Variant &AValue) { switch (AItem->DestField->DataType) { case ftGuid: AValue = DMDatabase->GUIDFromServer(); break; case ftString: case ftWideString: break; case ftAutoInc: if (Variants::VarIsNull(AValue)) { AValue = FAutoIncVal++; } break; case ftDate: case ftDateTime: case ftTime: // NULL could be valid. Only reformat dates and times // that aren't NULL. if (!Variants::VarIsNull(AValue)) { try { AValue = Sysutils::StrToDateTime(AValue); } catch (...) { } } break; default: break; } } //--------------------------------------------------------------------------- You could look for the '--' string here.

What I do after GuessFormat() is fix all the types that GuessFormat() assumes to match the destination. The main issue I had was float columns being detected as integers. Do you use the TDBatchMove.OnWriteValue event? void MapTextReaderTypesToDestination(TFDTextFields* text_reader_, TFields* dest_) { for (int i = 0; i < text_reader_->Count; ++i) { auto field_ {dest_->FindField(text_reader_->Items[i]->FieldName)}; // I don't like the looks of indenting the switch statement below // inside of an if statement ;-) if (field_ == nullptr) { continue; } switch (field_->DataType) { case ftAutoInc: text_reader_->Items[i]->DataType = TFDTextDataType::atLongInt; break; case ftBCD: case ftCurrency: case TFieldType::ftExtended: case ftFloat: case ftFMTBcd: case TFieldType::ftSingle: /* // If there is a single 0 in a column that is one of // the above field types (e.g. import file contains "hello",0,1,0) // GuessFormat will think the 0, 1 and 0 values // columns are integer and there will be an error // during import if we don't specify the correct type */ text_reader_->Items[i]->DataType = TFDTextDataType::atFloat; break; case ftDate: text_reader_->Items[i]->DataType = TFDTextDataType::atDate; break; case ftDateTime: case ftTimeStamp: case ftTimeStampOffset: text_reader_->Items[i]->DataType = TFDTextDataType::atDateTime; break; case ftString: case ftWideString: text_reader_->Items[i]->DataType = TFDTextDataType::atString; break; case ftTime: text_reader_->Items[i]->DataType = TFDTextDataType::atTime; break; default: ; } } }

Do you use GuessFormat() prior to doing the TFDBatchMove.Execute?