rvk

Do you see the cpu for "Antimalware Service Executable" process skyrocketing when you compile in D7? Did you try disabling some of the "Exploit protection"-settings (i.e. CFG and DEP) of Defender? (Setting > Security > App & Browsercontrol > "Exploit protection settings" at the bottom) If that works you can enable it again and only exclude your processes from it.

If your application is 32bit you also should use the 32 bit dll's. Not the x64 bit ones. Putting them in your exe directory and not using IdOpenSSLSetLibPath should also work.

At the moment Google probably has marked the download as safe because it is downloaded multiple times. In the future, if Crome is blocking the download with only a discard option, you can go to "Downloads" page of Chrome and there should be an option to keep the download.

Did you download the 32 bit version or the 64 bit ones? The DLL bitness must match your programs bitness. There shouldn't be any need to set the IdOpenSSLSetLibPath. But if you want to set it, you can do it with: Initialization IdOpenSSLSetLibPath(ExtractFilePath(Application.ExeName));

Those licenses could also be revoked after some time by Microsoft. You will never know beforehand. https://www.howtogeek.com/392080/cheap-windows-10-keys-do-they-work/

This should have no impact for application passwords. Your application doesn't even need to be changed. Just use the application password instead of the regular GMail password.

You don't need LoadLibrary/FreeLibrary if you use a static function definition like "external myDLL". So use either LoadLibrary/GetProcAddress/FreeLibrary or use function/external myDLL. Also... you use a string as parameter. That is a managed type. I'm not sure but that might give you problems.

Ah, yes. But Dmitry gave an example of SelectQuery.Transaction := ReadTransaction; So I was talking about setting the actual transaction properties rather than talking about the fact the transaction-property itself is used or not. It indeed seems to be that some of the explicit transaction assignments only work for Interbase/Firebird (???). Also for the transaction of a TDataset: http://docwiki.embarcadero.com/Libraries/Rio/en/FireDAC.Comp.Client.TFDRdbmsDataSet.Transaction How would one set transactions with specific isolation level for MSSQL and Oracle then ??? Doesn't FireDac support these? This page does mention setting isolation level but also mentions it is for Firebird/Interbase. http://docwiki.embarcadero.com/RADStudio/Rio/en/Managing_Transactions_(FireDAC) (FireDac might be even more rubisch than I initially thought if you can't set isolation level etc for other databases via the standard property)

As long as you use the standard properties and values to set the isolation levels etc., they will work for all databases. Most databases have transactions and you should be able set them the same way. i.e. MSSQL and Oracle etc. all have Read Committed transactions levels. So transactions work the same way. Only when setting special properties via the params, you'll get database specific.

By setting the correct isolation level, record version and wait-option for the transaction. https://ib-aid.com/en/how-to-track-deadlocks-in-firebird/ As I said I'm not familiar with FireDac so I'm not sure how to set it. https://stackoverflow.com/a/56337589/1037511 (Something like read_committed, rec_version and nowait should fix deadlocks on select)

For good measure I would add Connected := false after dbQuery.ExecSQL; (But my guess this is also done in dbConn.Free) dbQuery.ExecSQL; dbConn.Connected := false; But I see you update the table in the thread. You didn't do that in your original post. The deadlock can come from using transactions incorrectly (or updating the same record in different transactions/threads), http://www.firebirdfaq.org/faq151/

It's not if you're using a pool. When using a pool the connection is given back to the pool. It's not closed. At least that's what the documentation says. http://docwiki.embarcadero.com/RADStudio/Rio/en/Multithreading_(FireDAC) But maybe the TFDConnection.Free already does that. What's your code like now?

Maybe putting a amNonBlocking in there? FDQuery1.ResourceOptions.CmdExecMode := amNonBlocking; You're not updating anything so I'm not sure why there would be a deadlock there. You set the TFDConnection.Connected to false afterwards in the thread? (because that releases the connection back to the pool)

Yes, that sometimes happens to me too. Often this is due to the IDE not recognizing some lines and not knowing it already has a {$R *.res} line. Sometimes reordering the uses-units and other elements will fix this (if it keeps happening). (I had to move my {$R} lines above the uses- and {$SETPEFLAGS} lines.)

Look in your project source (the .dpr file)... do you have multiple {$R *.res} lines?