weirdo12

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.

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?

Of course, if you'll never need to support a client/server installation it makes no sense.

Agreed. That said, there are developers in the space we work in (in fact most of them) that include SQL Server Express as default database for a small single-user app. That or Access. If you have not worked with PostgreSQL you should check it out.

It might not have been clear in the original post that SQLite is our default database (and it has been since 2021). Using FireDAC, the same install supports SQLite, PostgreSQL, SQL Server, SQL Anywhere and MySQL,