Dmitry Arefiev

When FDQuery's use ConnectionName, then single temporary TFDConnection will be created transparently and used by all FDQuery's, etc

FireDAC TFDTable emulates BDE/Paradox TTable behavior using LDW mode. This is expensive, and disabling LDW mode will improve performance. More info: http://docwiki.embarcadero.com/RADStudio/Sydney/en/Browsing_Tables_(FireDAC) But anyway, you will never get 100% similar performance to BDE/Paradox TTable with big tables. Any TxxxTable will request DB server and will fetch the data. When data is fetched, then operations will be fast and similar to TTable.

Yes, it is. But you can use always full object (table) name.

Other option is to use TFDManager.CloseConnectionDef http://docwiki.embarcadero.com/RADStudio/Sydney/en/Multithreading_(FireDAC)#Connection_Pooling

FDManager.Active := False; // change what you need

Q3 at http://docwiki.embarcadero.com/RADStudio/Sydney/en/TFDQuery,_TFDStoredProc_and_TFDUpdateSQL_Questions

Most right way will be to create an issue at quality.embarcadero.com. And attach the DB file with the words explaining what you did. I would expect, dates were inserted using format not supported by FireDAC.

Sorry for spamming, dont know how it happened ...

You have to read: http://docwiki.embarcadero.com/RADStudio/Sydney/en/Using_SQLite_with_FireDAC#SQLite_Data_Types http://docwiki.embarcadero.com/RADStudio/Sydney/en/Using_SQLite_with_FireDAC#Adjusting_FireDAC_Mapping

You have to read: http://docwiki.embarcadero.com/RADStudio/Sydney/en/Using_SQLite_with_FireDAC#SQLite_Data_Types http://docwiki.embarcadero.com/RADStudio/Sydney/en/Using_SQLite_with_FireDAC#Adjusting_FireDAC_Mapping

May be this will help: https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi

1) If server is publicly accessible, please, log this issue to quality.embarcadero.com and attach simple test project. If there is some sensitive information, which you dont want to share publicly, then let me know. We can exchange it privately. 2) Otherwise, you can try to analyze the server using https://www.ssllabs.com/ssltest/ This may give some hints.

Try to leave only TLS v 1.1 and 1.2 in SecurityProtocols.

Please report this issue to quality.embarcadero.com, and get it fixed in 10.4 Update 1.

Start from this link: https://dev.mysql.com/downloads/c-api/

This will be fixed in 10.4 Update 1.

https://quality.embarcadero.com/browse/RSP-28886 try to run: sudo apt-get install curl

Thanks a lot ! The proposed here changes will be in 10.4 Update 1 with some modifications. Mostly due to new cross-platform AtomicCmpExchange128 for 64bit platforms.

This is known issue: https://quality.embarcadero.com/browse/RSP-19708

1. libmysql.dll must be in EXE folder, or in some folder which is in PATH, or in SysWOW64 for x86 and System for x64. 2. libmysql.dll must have the same bitness as EXE. Simple way to verify it: tdump libmysql.dll | find "CPU type" 3. libmysql.dll v 8 is not yet supported. Use version 5 or 6. Which one - almost not important. 4. Note, that libmysql.dll, depending on version, depends on MS C RTL.

You can try to do: FDUpdateSQL1.Commands[arInsert].CommandKind := skSelect;

Could you please provide RSP numbers. May be even you can provide your patch.

FDMetaInfoQuery1.MetaInfoKind := mkResultSetFields; FDMetaInfoQuery1.ObjectName := 'RESOURCE'; FDMetaInfoQuery1.Open;

Beside what @Vandrovnik said, Delphi with each one new version is getting more and more "green" (in the sense of Greenpeace, or energy class). What in past consumed N CPU cycles, now may consume less or much less. Want to make the World more green ? Upgrade your Delphi 🙂 PS: Of course, this is questionable statement. But it is true in many Delphi areas ...

For SQL Server the AName parameter usage is not specified.