Der Fehler kommt nicht von der Stelle. Der kommt von früher. Das Disconnect tut nichts. Die Implementierung ist leer.
Aus irgendeinem Grund ist der
Handle auf die
DB Session ungültig, vermutlich auf der Serverseite. An sich genügt es, auch wenn es nicht sauber ist die Excpcetion zu bügeln bis die Migration vorbei ist und dann eine passende Client Library zu suchen oder möglw. zuvor.
Es genügt ein isoliertes AnyDAC Beispiel um mal zu zeigen ob die Client Library an sich mal funktioniert. Hernach die
BDE dazu tun. Irgendwann mal müsste sich das Phänomen zeigen.
Es gab Fälle in den die die anderen Komponenten einfach sagten, 'Danke und schönen Tag liebe
DB'.
Ich kann mich noch an Fälle vor 8 erinnern als die großen Migrationswellen waren, da kam es hie und da vor, dass eine andere Library die Gegenseite.
Das Timeout kann viel sein. In der C-
DLL eine Absturz. Die kennen keine Exceptions. Ich vermute am Client tracen hilft. Nach Bauchgefühl wohlgemerkt halte ich das für wahrscheinlicher. Wie du sagst ohne den Code. Wenn das Programm zuvor lief könnte ich mir vorstellen, dass entweder die
DB wurde abgegradet oder die Library getauscht oder eine andere wird geholt aus irgendeinem Grund.
Hallo,
Zitat:
Nun stellt sich mir die Frage warum der CommandCount falsch ist, oder ein TADCustomCommand Objekt nicht mehr verfügbar ist.
Laß Dir doch von beiden irgendwas eindeutiges anzeigen, ich nehme meist
Name oder
ClassName.
Das passt hier ja wohl nicht.
Es könnte sein, dass Du irgendein Command-Objekt doppelt freigibst oder "falsch" freigibst.
Was auch immer "falsch" bedeutet.
Kannst Du das ganze Problem nicht mit einer separaten Beispiel-Exe nachvollziehen,
die nur minimalen Code enthält?