Jupp, es gibt nur zwei drei Wege, um sowas zu lösen:

* Die Arbeit im Hauptthread, dann kann die VCL dort halt so lange nichts machen. (nur Grafik/Wartemauszeiger zu Beginn, währenddessen halt unbewegt und zum Schluß wieder weg ... in der Hoffnung Windows reagiert nach standardmäßig 3 Sekunden nicht mit "Fenster reagiert nicht mehr")

* Die Arbeit in einem Thread, dann kann der Hauptthread in Ruhe die Wartegrafik aktualisieren
* Arbeit im Hauptthread, aber dort wird z.B. über einen Callback oder regelmäßig ProcessMessages der Wartegrafik Zeit gegeben.
* Oder Arbeit im Hauptthread und die Wartegrafik im Thread.



Wir blenden z.B. bei längeren Aktionen, bzw. nach kurzem Warten, ein Fenster (nicht VCL) ein, in einem anderen Thread erstellt und behandelt, wo per Button oder per Strg+ESC (GetAsyncKeyState) abgebrochen werden kann.
Unsere DB-Komponenten haben eine Methode, womit man sie aus einem anderen Thread heraus abbrechen kann (also wo versucht wird dem DB-Server ein Abbruchsignal zu senden, bzw. die Connection getrennt wird, wodurch die wartende Aktion im Hauptthread abbricht)

Ursprünglich auch versucht die DB-Aktion in den Thread zu verschieben und das WarteZeugs im Hauptthread, aber trotz viel Arbeit mit Blocking, ConnectionPooling uvm. hatte es immer wieder mal geknallt, da ja öfters VCL-Komponenten und Events ungeschützt an den Queries hingen.