Also ich habe mich mit der Notwendigkeit von Application.ProcessMessages in meinem konkreten Fall nicht weiter beschäftigt. "Mit" geht es, "ohne" halt nicht.

Mein Thread speichert einen (neuen) Eintrag in ein TAdoQuery in einer Access (.mdb) Datenbank. Wenn AdoQuery.Post durchgeführt wurde, und das AdoQuery und die AdoConnection wieder freigegeben sind, wird über Synchronize die Prozedur oben aufgerufen, welche die Übersicht mit den Tabelleneinträgen neu zeichnet ( == neue Abfrage durchführen, dieses Mal ohne Thread).

Ohne Application.ProcessMessages wird der gerade gespeicherte Eintragt nicht mit angezeigt. AdoQuery.Post ist ja abgeschlossen, also müssen die Daten ansich schon in der Tabelle stehen. Tun sie aber scheinbar "noch" nicht. Ein manuelles Neu-Zeichnen eine Sekunde später schafft Abhilfe. Mit der Verwendung von Application.ProcessMessages vor dem Neuzeichnen scheint alles problemlos zu funktionieren; der neue Eintrag wird direkt angezeigt.

Hm... habe ich mal irgendwo gelesen, dass ADO/COM/OLE/JET trotzdem immer irgendwie über den Haupt-Thread läuft? Das würde erklären, warum die Daten erst nach Application.ProcessMessages drinnen stehen.

Das Ganze ist zwar ein sehr interessantes Thema, allerdings kein offenes Problem. Bevor wir uns jetzt tot-spekulieren: Es funktioniert, und "irgendwie" kann man das Ganze bestimmt "professioneller" oder optimaler Programmieren - keine Frage.

Falls jemand fundierte Hintergrundinfos hätte, um dieses Phänomen zu erklären ware cool, aber so wie es jetzt ist funktioniert es, und -wie es bei Computern halt so ist- manchmal muss man halt akzeptieren, dass etwas funktioniert obwohl es nicht sollte (und anders herum), aber dann sollte man das auch einfach mal so hinnehmen und sich drüber freuen