Hans J. Ellingsgaard

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.

MS SQL server can have deadlocks, just like any other database.

You can minimize the deadlock problem, if you call starttransaction just before the ExecSQL, and call CommitTransaction right after ExecSQL. Then you also can make a controlled RollBack in case of an error.

For Interbase the default username and password has been SYSDBA and masterkey, has it changed in later versions?

Yes you'r right. I was thinking about a single user client with multiple datamodules.