Fred Ahrens

Wow. We started using CDATA connectors already two years before Embarcadero started bundling it with some of the Delphi SKUs. I wasn't aware that license conditions have changed. I just checked and compared with older EULAs shown during the CDATA component installation and there wasn't a limitation to inhouse distribution only. The 2018 version of the EULA was more similar to typical other component packages - only the typical restrictions did apply. With this license change we'll have to stop using CDATA components. I guess we could afford to pay the costs for upgrading our existing licenses and bring them back to a royalty-free distribution model. Finally it would be a stupid investment as we don't know what other changes might be introduced in the licenses through the backdoor and might render our investment useless (again). I'll be happier with spending that money at other component developers who have a more developer-friendly business model.

The drivers are available for download at https://www.cdata.com/drivers/. You will need to choose the driver you want to download. At the top of the next page you will need to choose "Firedac" from the toolbar. On the next page click on "Download" and on the final page "Download Full". The "Download Full" button looks disabled but is working and downloads the licensed version of the driver. You will need your product key (it's the same for all CData drivers) for starting the download.

Sometimes the source of such problems isn't obvious at all. A while ago while having similar problems for a long time I observed in the Events window in the IDE when starting the app, a dll belonging to my Razer headset got injected into the app and caused a lot of strange behavior. After uninstalling the headset's driver, everything went back to normal. Whenever I have similar problems, first I disable all non-essential programs in Task Manager > Startup. Disabling Windows Updates isn't a good idea. I'm not talking here about security and 0day exploits. Assuming that most developers have the Windows Update set to normal settings brings you to the same level as other developers and will give you a better chance to find somebody who might have similar problems like you and who might already have a solution.

My brain would detect this as an error while reading the code. I always expect to see in the source code the characters I did type and not the characters the IDE "thinks" might look better.

For testing I uploaded your file to our own domain and still get the error while downloading it from there. So the source of the download doesn't seem to be the source of the problem. It seems to be a problem with the digital signature. It may help to add a second signature using sha1 digest algorithm. It won't hurt and will give you also some compatibility with downloading the file on older Windows versions. This will also change the checksum of your file and provides a good chance that it won't be detected again that has been flagged as critical due to unknown reasons. Some years ago we also used Comodo certificates. When we had similar problems it helped just to sign and upload the affected file again. Meanwhile we switched to DigiCert signatures and those problems went away. This also lowered false positive detection of our binaries by some virus scanners.

I'm just guessing: It could be a problem that the file isn't downloaded from your domain but from storage.googleapis.com. At the end whenever another identified malware was downloaded via storage.googleapis.com your downloads are flagged as well as potential malware - you just don't have this under control as anybody can use this domain for downloads. I would try moving the downloads to your own domain.

Some years ago we needed to implement a Modbus interface for reading data from an automation system. After trying several libraries we ended up using http://www.ozm.cz/ivobauer/modlink/ It's not free but worth the investment.

Happy Birthday.

You'll need a code signing certificate - SSL certificates can't be used for code signing. Developers can get a discounted code signing certificate from Digicert via this link -> https://www.digicert.com/friends/sysdev/

Deep in the release notes I have seen some comments regarding the implementation of some of Andreas' patches directly into the official release. But I couldn't find any further info if this is the full feature set of the Fix Pack or only a few selected patches.

You may need to upgrade your Comodo digital signatures. As far as I remember Comodo signatures are considered unsafe now (see: https://bravatek.com/comodo-certificate-hack-it-gets-worse/)

I have no hard evidence here. We had the problem for a while and it also took a while (several months) for tracking this down to the LiveBindings. I remember we had hope that Tokyo would solve the problem - but it didn't. And if I remember right, the performance problem wasn't that big in Seattle. Meanwhile we use two profiles in Delphi: one with and one without LiveBindings. I just created a shortcut to bds.exe on my Desktop with parameter -rUseLiveBindings (you can use whatever name you prefer). The default profile has LiveBindings disabled (also for mobile), and the second profile has LiveBindings enabled. The downside of this approach is, you'll need to install all 3rd party component packages for both profiles. But you may copy all entries in registry from HKEY_CURRENT_USER\Software\Embarcadero\BDS\19.0 to HKEY_CURRENT_USER\Software\Embarcadero\UseLiveBindungs\19.0 first before making the individual adjustments to each profile. (as mentioned before "UseLivebindings" is the name you assign to this second profile via the -r command line switch).

We had the same problem with very slow opening of forms. At the end we tracked it down to a problem with LiveBindings. Disabling LiveBindings (removing the related component packages in the IDE) accelerated the opening of forms dramatically. That's of course a solution only for projects where you don't rely on LiveBindings.