Deine Eingangsfrage war ja erst mal, ob Threads überhaupt nötig sind an dieser Stelle. Da wäre die Gegenfrage: Soll denn noch irgendwas anderes passieren, während die Abfragen laufen? Soll der Benutzer noch an anderer Stelle im Programm arbeiten können? Oder möchtest du einfach nur, dass das Programm nicht den Eindruck macht, es sei eingefroren?

Das ging aus deiner Beschreibung nicht so ganz hervor.

Bis denn
Bommel

Letzteres.

Ich selbst würde es in dem Fall wohl eher so machen, dass ich ohne Threads arbeiten würde. Eher würde ich dem Benutzer mitteilen, er möge sich jetzt etwas gedulden und dann die Datenbank-Operationen ganz normal im Hauptprogramm starten. Zwischendurch vielleicht bei passender Gelegenheit noch ein paar "Application.ProcessMessages", damit das Programm nicht völlig tot wirkt.

Falls du natürlich einfach nur auf eine Gelegenheit wartest, das Thema Threads näher kennenzulernen, könntest du das Programm so etwas aufhübschen.

So meine Einschätzung...

Bis denn
Bommel

Ist Threading da wirklich das Richtige?

Wenn die erzeugten Tabellen systemweite Bedeutung haben und kein individuelles Reporting darstellen, ist die Erzeugung doch eher Serveraufgabe oder?
Wie lange wird es denn dauern, die Tabellen zu erzeugen?
Was passiert, wenn der User (dank Threading )gar nicht merkt, dass da noch was läuft und seine Anwendung schließt?
Was passiert, wenn die Hauptanwendung abschmiert oder das System der Hauptanwendung?

Idee:

• Business OP serverseitig definieren, ggF. nebenläufige Teile.
• Start über Client nebenläufig

(dafür gibt's je DB und OS verschieden nette Möglichkeiten schon in der DB, notfalls Cron oder AT, bzw SchedTask bei MS WIN als Server )

Threading im Client für Statusfenster
(die berühmte Prozentanzeige)