Hans J. Ellingsgaard

If you use a FDQuery instead of FDTable, you could cast your datetime field to date. Then you can filter on that date field.

Have you checked in wich folder your dll file is located?

If you use the StartTransaction command, you have to finish it off with CommitTransacton or a Rollback. If you're not using a StartTransaction, the FDConnection will start it for you and make a commit when your datasets are closed.

Yes, the developer edition can run via tcp. Have you checked wich port it's using? You can do that with netstat. You should also be able to telnet the portnumber..

If you connect via tcp/ip, it should not matter where your Interbase binaries are located, as long as the interbase service is running. You also need to check wich port it is running on. Normaly it's on port 3050.

Your problem might have something to do with nested transactions. If your db or your odbc driver don't support nested transactons, make shure there is no ongoing transaction on the same connectionm, before you call StartTransaction. Something like this: if FDConnection1.InTransaction then FDConnection1.Commit; FDConnection1.StartTransaction;

A primary key is a ground rule of relational daatabases.

Your problem could come from the gds32.dll client file. If it's in the windows\system32 folder it will be overwritten with each installation. Not all of them have been backward compatible.

It works fine the opposite way - active at designtime and closed at runtime. I guess that most users use it that way. I allways make shure that all my queries are closed at programstart, and then open them via code.

I have converted from IBX to FireDAC without any problems with the datetime fields. What database are you using?

The Ryzen 5 processor is more than capable of running VM's on your PC. If it's not for gaming, go for a business PC, they have better hardware quality.

Have you checked if your interbase service is running? You can try to connect to it with tke IB Consol that comes with the Interbase installation.

Could it be this problem you have run into? https://www.ideasawakened.com/post/rad-studio-10-4-2-is-now-available-with-possible-cure-for-the-blue-dot-problem

Check in your project folders to see if there is a dbgrid.pas or dbgrid.dcu file and remove it, if it's there.

Is there anything that prevent you from indexing all the fields in the join and where clause? There is a good chance that it would give you a significiant boost on your query performance.

If you make a select count query on an indexed field, it should only take a ms to execute. The resultset will only have one record. If your table only have 1500 records, the dataset.RecordCount should also respond quckly (not as quick as the record count thoug). There must be something else that goes wrong. What database are you using? Have you tried to run the queries directly in a db manager?

A count(*) should always be done an an index field, or the point of using it is gone in the first place.

To fetch all the records from a table to get the record count is in most cases a bad praxis. If it's a table with a lot of records, you will just put a lot unnessisary strain on the database server. A count(*) query, on the other hand, has a very limited impact on the server.

You can use an extra query with a count(*) to get the number of records.

Have you tried IBExpert?

You can analyze your queries in IBExpert, but you need the paid version to be able to see all the details.

You will need a vpn connection between the datasnap server and the local network. SQL queries over an internet line is very slow, but if it's only a few records, maybe you can live with it. You would be better of writing some REST services to communicate between the two hosts.

I'm no expert in threads, but I'm shure that a LoadFromFile should be synchronized. As stated above the try/finally is pointless. If you only have these two commands in the thread, and both will be synchronized, there will be no point in putting them in a thread. It will probably just slow your program down.

Firebird is free. With Interbase you will have to pay for a license. I'm shure that both will serve you well, with RDBMS or as embedded.

But you would get rid of all the trouble of sync‘ing the data, if you kept the data on the server. With a REST service you will probably be able to load the data much faster, and save a lot of bandwith - at least if you are on a slow network.