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!