Ich beiße mir gerade die Zähne an folgendem Problem aus

ich habe hier ein TBetterAdoDataSet mit einem Async Data Fetch (non blocking)

dabei mache ich folgendes

aDataset.DisableControls;
try
aDataset.Close;
...
aDataset.Open;
finally
aDataset.EnableControls;
end;

Das EnableControls dauert bei sehr vielen Datensätzen sehr lang (bis zu 10sec) aber schlimmer ist wenn während dem EnableControl die Anwendung beendet wird - häüfen sich die Exceptions ...

gibts da einen besseren Ansatz?

Wenn das so lange dauert, hast Du einen Denkfehler in deinem System. Vermutlich enthält deine Tabelle sehr viele Daten. Wieso ziehst Du die alle in den Speicher?

alzaimar hat folgendes geschrieben:

Wenn das so lange dauert, hast Du einen Denkfehler in deinem System. Vermutlich enthält deine Tabelle sehr viele Daten. Wieso ziehst Du die alle in den Speicher?

stimmt es können sehr viele Daten in einer Tabelle sein (nur "in Extremsituationen") und nur dann tritt das Problem auf ...

Es ist doch logisch, das der Client dann lange benötigt. Filtere deine Daten, also lade nur die Werte, die man auch sehen kann, und lade bei Bedarf nach ('on-demand-fetching'). Das ist zwar etwas komplizierter, aber dann kannst Du in der DB 300.000.000.000.000 Werte haben (oder sogar noch mehr ) , deine Anwendung ist immer noch genauso schnell, wie am ersten Tag.

Über diese Technik gibt es hier diverse Threads. Wenn Du eine Tabelle mit sehr vielen Datensätzen hast, dann kannst Du z.B. die Werte 'häppchenweise' einladen. Wenn Du dann durch diesen Block durchscrollst und ans Ende stößt, lädst Du den nächsten Happen usw.

Wenn Du sehr viele Master-Detail-Beziehungen hast, dann lädst Du die Details nur dann, wenn der Anwender sie sehen will.

alzaimar hat folgendes geschrieben:

Es ist doch logisch, das der Client dann lange benötigt. Filtere deine Daten, also lade nur die Werte, die man auch sehen kann, und lade bei Bedarf nach ('on-demand-fetching'). Das ist zwar etwas komplizierter, aber dann kannst Du in der DB 300.000.000.000.000 Werte haben (oder sogar noch mehr ) , deine Anwendung ist immer noch genauso schnell, wie am ersten Tag. Über diese Technik gibt es hier diverse Threads. Wenn Du eine Tabelle mit sehr vielen Datensätzen hast, dann kannst Du z.B. die Werte 'häppchenweise' einladen. Wenn Du dann durch diesen Block durchscrollst und ans Ende stößt, lädst Du den nächsten Happen usw. Wenn Du sehr viele Master-Detail-Beziehungen hast, dann lädst Du die Details nur dann, wenn der Anwender sie sehen will.

Danke für den Hinweis - der Hintergrund für die lange Lesedauer war mir eigentlich schon klar - es wird aber auf jeden Fall auf das 'on-demand-fetching' hinauslaufen - nochmals Danke!

nun habe ich (das Problem) die Lösung gefunden

Der von mir gewählte Async Data Fetch (TBetterAdoDataSet - Execute Options eoAsyncFetchNonBlocking) war nicht das Problem - das Problem war der Async Execute (TBetterAdoDataSet - Execute Options eoAsyncExecute) - das EnableControls scheint auf das Ende vom Async Execute zu warten - wird die Anwendung in diesem Zeitfenster beendet kommt es zu "unerfreulichkeiten" bis zum Deadlock.
Nun ist der Execute Syncron (in dieser kurzen zeit "blockiert" die Anwendung die Zeit für den Execute ist aber < 2-3sec und damit akzeptabel)