0

We have an application written in Delphi Tokyo in which we use ADO components to connect to an SQL database. The whole application uses the same connection and a single thread.

Because we are dealing with some performance issues we consider the possibility of some things running in separate threads "in the background" so that the user does not have to wait for the delay. For example:

  • When the user presses the "Save" button, we have procedures (SQL commands like INSERTs, UPDATEs) which run right when saving the record to the database.

The user should not wait for all this work to end - we thought to put what is running when saving into another thread that will run "in the background".

  • Is this something that is common practice?
  • Are there "processes" within an application that you usually put in a separate thread?
  • Could someone advise me what to look out for when starting to use more than one thread in an application?
AmigoJack
  • 5,234
  • 1
  • 15
  • 31
P.A
  • 11
  • 4
  • Just look at [simple examples](https://stackoverflow.com/a/3451813/4299358). The usual downside of threads is that everybody expects them to always fully succeed, so people are even less prepared for when i.e. saving to a DB fails for whatever reason (i.e. disk space full). – AmigoJack Nov 05 '21 at 11:38
  • You will also need to add the ActiveX unit to our thread then call CoInitialize before using any ADO objects you create and call CoUninitialize when the thread ends. You only need to call CoInitialize once per thread, so do it first in your Execute method. – TDC Nov 05 '21 at 12:14
  • 1
    There usually is little benefit to putting operations that are under direct user control, and for which the user has to wait anyway, in a separate thread. What else is the user going to do while they wait for their "save" to complete anyway? – Freddie Bell Nov 05 '21 at 17:57

0 Answers0