Neue Informationslage:
TUniConnection.AssignConnect() war keine gute Idee, da es tatsächlich die die ganze Connection umbiegt, und nicht nur die Logindaten und Serversettings setzt. Also das raus geworfen, um wirklich getrennte Connection zu haben, in beiden Threadklassen. Das Problem besteht allerdings weiterhin
Interessant ist jedoch:
Im TMySubThread.Execute() wird die meiste Zeit keine
Query abgesetzt, da dies nur bei einer Änderung gemacht wird, die zuvor dort ermittelt wird. Bisher habe ich nur ohne Änderungen getestet. Setze ich dort wirklich eine
Query ab, gibt's eine
AV - was zu erwarten war. Stecke ich dies nun also in ein try..except, und schreibe im Ausnahmefall manuell "FConnection.Disconnect;", ist der Wert von FConnection.Connected in der Folge korrekt. Ich muss aber um das zu merken erst auf den Hammer laufen, was in TMyThread nicht nötig ist.
Doof dabei ist: Änderungen treten teils länger nicht auf, und so lange dem so ist, merke ich den Disconnect nicht. Allerdings ließe sich eine Menge Netzwerktraffic (den ich bei bestehender Verbindung auch anderweitig erzeuge, Polling... bäh), so wie ein Haufen unnützer Log-Einträge sparen, wenn ich den Disconnect schon merken würde wenn er passiert ist. Immer und immer wieder, auch bei keinem Bedarf, eine
Query nur zum Prüfen der Verbindung abwerfen fände ich aber auch nicht so genial, zumal es in TMyThread ja geht.
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)