Hallo zusammen,

ich habe gerade eine Programmieraufgabe bekommen, von der ich denke, dass es vllt. Sinn macht dies mit Threads zu erledigen (wäre das erste mal das ich richtig damit arbeite und alleine das ist schon ein Grund, damit ich das "by doing learne" (hoffentl. ist hier kein Engländer, dem jetzt schlecht wird)). Trotzdem wollt ich mir da vorher mal einige Meinungen zu einholen und vllt. auch schon ein paar Tipps abholen .
(Luckies Tutorial hab ich gerade begonnen durchzulesen, wollte aber parallel dazu hier schonmal die Ausgangslage schildern).

Das Programm soll über komplizierte, langedauernede SQL-Abfragen Daten aus diversen Tabellen zusammensuchen und neue Tabellen mit dem Ergebnis der Abfragen erstellen (Create Tabele ABC as (Select...)). Insgesamt sollen so 8 Tabellen erstellt werden, die teilweise aufeinander aufbauen, d.h. Tabelle 2 kann erst nach Tabelle 1 erstellt werden, teilweise aber auch nicht, so kann z.B. Tabelle 3 direkt erstellt werden. Tabelle 4 braucht dann aber schon wieder Tabelle 2 und 3.

Ich sehe das so, dass Threads eingentlich erstmal nicht nötig sind, ich das ganze also auch linear hintereinander abackern lassen kann. Bis auf die 2-3 unabhängigen Tabellen, die ich parallelisieren könnte, hätte ich keinen Performance Gewinn, oder?

Das Programm ist aber während der Ausführung nicht ansprechbar, d.h. diese Geschichten in Threads auszulagern würde das Hauptprogramm ansprechbar bleiben lassen, oder?

Zur Vorgehensweise: Würde man alle Threads gleichzeitig starten und Thread 4 macht erst mal nix, bis 2 und 3 melden, dass sie fertig sind oder lässt man dem Hauptprogramm die Kontrolle, so dass es z.B. Thread 1 und 3 startet, Thread 2 wenn 1 fertig ist, Thread 4 wenn 2 und 3 fertig sind?

Soweit ich das mit der Klasse TThread verstanden habe, erstelle ich einen Nachfolger davon, der eine Funktion enthält, die dann ausgeführt wird. Kann ich der Funktion schon einen Parameter mitgeben (z.B. im Konstruktor der Klasse oder so)? Hintergrund: Ich bräuchte dann nur einen Nachfolger von TThread, da meine "Threads" ja immer das selbe machen sollen:
- SQL-Statement aus Datei laden (d.h. Pfad muss übergeben werden)
- Neue Tabelle erzeugen (d.h. Tabellenname muss übergeben werden).

Wie ist das mit der Datenbank Connection (ADO)? Brauchen alle Threads eine eigene oder können die sich die Teilen? Macht das Sinn?


Mehr Fragen kommen bestimmt, wenn ich mit dem Tutorial durch bin und es an die konkrete Umsetzung geht (es sein den ihr seit der Meinung, das Threads in dem Zusammenhang keinen Sinn machen).

Danke schonmal an die, die sich den Roman bis hierher durchgelesen haben,

Jumpy

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.

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)

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