Die Connection hatte ich auch schon unter Verdacht, da die schon mal mein Problem mit Threads war - daher die eigene Connection für den TFetchThread, beim DBEntryThread hab ich das vergessen. Das wäre auch schon gefixed gewesen, wenn nicht schon die Variante von DBEntryThread, die überhaupt nichts macht die ganzen Fehler beim Create werfen würde! Das ist der Teil, an dem ich den ganzen Tag verzweifel: Das bloße Erzeugen eines Threads, der wirklich nichts tut, also komplett leere Execute-Methode und leerem Konstruktor (bis auf das von Blup angesprochene) führt zu den genannten Random-Fehlern. Und zwar nicht in einer der 3 Zeilen im Konstruktor, sondern erst in der Methode, die den Konstruktor aufruft - dort aber unmittelbar in dieser Zeile. Aus diesem Grunde bin ich von den DB Dingen erstmal weg, weil eben auch ganz ohne rummst es schon unverändert. Wenn das dann mal gelöst ist, bekommen die auch ihre eigene Connection, oder eine gesharete mit Critical-Sections (dürfte deutlich performanter sein; alternativ Pooling an).
Der Witz ist ja, dass sogar die Variante mit voller Funktionalität (also incl. DB Zugriffen) klaglos tut, wenn das Erzeugen denn geklappt hat. Vermutlich eher Zufall, aber dort habe ich noch nie eine Exception gesehen. Der Hund ist im reinen Erzeugen des Threads begraben, und dort auch nur mit einer Häufigkeit von grob geschätzt 5-15% der Erzeugungen. Laut Taskmanager habe icha uch keine Probleme mit zu vielen Handles oder Threads, so lange das Programm läuft, bleibt die Anzahl derer im Mittel gleich. Daher scheinen die auch korrekt zu terminieren.

Ich habe den Weg mit nur einem Abarbeitenden Thread gewählt, weil leider die Zurordnung "Anfrage zu Antwort" nicht möglich ist (danke Siemens...), und es einfacher erschien einen einzelnen Thread warten zu lassen bis die Antwort zur letzten Anfrage da ist, als dies zwischen mehreren Threads (einer pro Anfragegruppe, oder gar dynamische Worker) zu synchronisieren. Die DB-Einträge sind eigentlich nur deswegen in einen weiteren Thread ausgelagert, da in der Zeit, in der das Update zusammengebastelt und ausgeführt wird ja ruhig schon die nächste Anfrage los gehen kann. Der Kram im DBEntryThread fand zuvor komplett im Kontext des TFetchThreads statt, hat diesen aber unnötig aufgehalten.
Und da eh klar ist, dass ich immer nach einer Anfrage auf Antwort warten muss, erschien mir die Variante mit einer Joblist für die DB Einträge überflüssig - da könnte eh immer nur einer drin stehen, also kann ich auch gleich direkt einen Thread zur aktuellen Antwort abfeuern. Eigentlich...

Da hilft eigentlich nur schrittweise Teile des Codes zu entfernen (z.B. die TCP/IP Teil) und die Funktion zu simulieren um den Rest der Anwendung einem Stresstest zu unterziehen.

Zitat von Medium:

Ich habe den Weg mit nur einem Abarbeitenden Thread gewählt, weil leider die Zurordnung "Anfrage zu Antwort" nicht möglich ist (danke Siemens...), und es einfacher erschien einen einzelnen Thread warten zu lassen bis die Antwort zur letzten Anfrage da ist, als dies zwischen mehreren Threads (einer pro Anfragegruppe, oder gar dynamische Worker) zu synchronisieren.

Ja, das kenn ich gut, "geht doch viel einfacher so", "wenn tatsächlich neue Anforderungen kommen machen wirs richtig..." usw., nur zahlt man so bei Fehlersuche und späteren Erweiterungen drauf.
Ein automatischer Unit-Test scheint mir in der jetzigen Struktur kaum möglich.

Zitat von Medium:

Und da eh klar ist, dass ich immer nach einer Anfrage auf Antwort warten muss, erschien mir die Variante mit einer Joblist für die DB Einträge überflüssig - da könnte eh immer nur einer drin stehen, also kann ich auch gleich direkt einen Thread zur aktuellen Antwort abfeuern. Eigentlich...

Das erscheint mir zumindest nicht klar. Es kann durchaus sein, daß der Zugriff auf die Datenbank länger dauert als normal. Im schlimmsten Falls ist die Verbindung zum DB-Server/Dienst gestört.
Falls dann tatsächlich zwei Anfragen kurz nacheinander abgeschlossen werden, existieren plötzlich auch zwei TDBEntryThread, aber nur eine Connection...

Die Anforderung wird es nie geben, das ist (und ich weiss, dass sich das schnell sagt) gesichert. Sollte sich je etwas an dem Protokoll ändern, sind ganz andere Dinge in Not. Ich weiss, dass das einem Informatiker schwer zu vermitteln ist (bin ja selber einer), aber vertrau mir hier.
Zudem sehe ich den wirklichen Unterschied zwischen einer Joblist mit einem Eintrag und dem direkten Übergeben dieses einen Jobs nicht so ganz. Das Verhalten ist an sich ja wohl definiert, und die Connection wird noch angegangen, das ist klar. Nur bringt mich das mit meinem eigentlichen Problem nicht so viel weiter, dass ja schon ohne Connection besteht
Wenn dann zwei oder mehr Threads eine eigene Connection haben ist das auch wieder okay, und eben genau für den genannten Notfall ist eine Timeout- und/oder Mengenüberwachung zumindest gedanklich schon da, damit sich nicht hunderte Threads+Connections aufbäumen wenns mal hakt

Ich werd wohl mal eine Kopie nach und nach ausziehen, und schauen was passiert. Mehr ist mir auch in meiner sonst sehr produktiven (und oftmals daher viel zu langen) Einschlafphase auch nicht eingefallen. Danke euch bis hier her schon mal kräftig!

Haste mal versucht diesen Parameter raus zunehmen

[DELPHI aCon: TUniConnection;[/DELPHI] im Create

Es kann nämlich sein das die aCon nicht mehr da ist das würde zumin. die seltsammen Esceptions erklären.

Ich hab früher auch mit MyDAC auch solche Probleme gehabt und Übertrage die USer Daten jetzt in einem Record wo die Parameter drin sind wie Username,pw .u.s.w. dann geht alles.

Die Connection ist schon lange nicht mehr drin, hab ich auch gelegentlich erwähnt Aber Blup, du bist mein Retter! Es war tatsächlich das suspended create! Sobald das raus ist, läuft alles wie gewollt. Da macht man's Jahre lang falsch, es ging immer, und dann trifft's einen von hinten durch die Brust (und kostet 1,5 Tage Kopfkratzen)
Ahhh, endlich geht's weiter. Erstmal die Connection fixen. Danke!