Tabelle Öffnen+Fortschittsanzeige

[Sugar]

Hallo Forum,

ich greife über die ADO-Komponeten von D7 auf zwei Tabellen einer MS-SQL Datenbank zu.

Wenn ich die Tabellen öffne dauert es aufgrund der immensen Menge an Datensätzen extrem lang bis die Anwendung die Arbeit fortsetzen kann.

Konkret habe ich im Designmodus die Komponenten mit der DB verbunden, aber die Tabellenobjekte auf ACTIVE:=False gesetzt. In der Anwendung (es ist nur ein Tool zur Datenmigration) schalte ich dann die einzelnen Tabellen auf ACTIVE:=TRUE;

auf Button-Klich passiert folgendes

Screen.Cursor := crHourGlass;
Panel2.Visible := true;
Timer1.Enabled := true;
Application.ProcessMessages;
// TAbelle öffnen
ANTBL.Active := true;

Der Timer sollte eigentlich die Caption verändern um so wenigstens Aktivität anzuzeigen. Aber er kommt wohl nicht zum reagieren. Das Öffnen der Tabelle ANTBL saugt alle Prozessorleistung.

Kann man irgendwo den Fortschritt der Aktion Tabelle.Active abgreifen und anzeigen?


Gruß
Heiko

[Mavarik]

hmm 3 Stickworte

- Kein Select *
- Immer N Datensätze nachladen..
- Laderoutine im Thread

[hoika]

Hallo,
nicht TADOTable benutzen, sondern TADOQuery
Cursor auf clUseServer.

[dataspider]

Keinen Timer verwenden...
sondern:

Code:

Label.Caption := 'Öffnen Tabelle A...';
Application.ProcessMessages;
TabelleA.Active := True;
Label.Caption := 'Öffnen Tabelle B...';
Application.ProcessMessages;
TabelleB.Active := True;

Frank

[sakura]

Die nächste relevante Frage ist, wozu Du in der Anwendung eine solche Menge an Datensätzen unqualifiziert laden musst. Ein Nutzer braucht eigentlich nie tausende Datensätze in der GUI, damit kommt der eh nicht zurande. Daher den Nutzer zuerst filtern lassen, zum Beispiel Datensätze mit Änderungen in den letzten 2 Wochen, oder alle "Schmidt"s... etc. Und dann lediglich die relevanten Daten laden, dazu, wie von hoika bereits angemerkt, TADOQuery und den Cursor serverseitig laufen lassen und es geht viel praktikabler für den Nutzer.

Natürlich mag es Situationen geben, in welchen man die Gesamtmenge an Daten benötigt, aber in einer nutzergesteuerten Anwendung warte ich bis heute auf diesen Beweis ;)

...:cat:...

[sakura]

Zitat:

Zitat von dataspider (Beitrag 1351587)

Keinen Timer verwenden...
sondern:

Hilft nicht sonderlich, wenn TabelleA bereits eine Minute zum Laden braucht, Dann werden die Nachrichten durch die Anwendung solange halt nicht verarbeitet...

...:cat:...

[himitsu]

Es kommt auch darauf an, was so lange dauert.
1) die Daten im DBMS zusammenstellen (Suchen, Filtern, Joinen usw.
2) die Daten vom DBMS ins Programm übertragen (Netzwerk)
3) die Daten in die Anzeige laden
3a) nur "aktuellen" Datensatz in paar TDBEdits ist immer gleich schnell, egal wieviel
3b) aber zu viele Datensätze in ein Grid rein, dauert schonmal ewig

Das erste kann man nur durch "Vorladen" schneller machen, also das bei Abfrage schon alles fertig und abholbereit ist.
z.B. Data Warehouse oder sonstwie vorher das "Ergebnis" in eine Temp-Tabelle schreiben

Und bei 2/3 kann man entweder manuell ein "Window" laden, also jeweils nur ein paar Daten LIMIT+Offset, aber da darf Punkt 1 nicht lange dauern, wenn man das Select mehrmals abschickt.
Oder die Query-Komponente und das Grid (und eventuell auch das DBMS) können einen passenden Modus, wo man die selektierten Daten dann Stück für Stück laden kann, also jeweils nur einen aktuell "sichtbaren" Bereich.


Punkt 1 und 2 kann man aber auch in einem Thread im Hintergrund laden, damit nicht die GUI so lange angehalten wird.

[Sugar]

Danke für die vielen Hinweise.

Mir ist natürlich klar, dass ich mit Queries arbeiten könnte, allerdings baue ich gerade keine userorientierte Oberfläche, sondern möchte Massenänderungen mit Userdialog durchführen. Jedesmal einen Datensatz zu selektieren, dannn zu prüfen, optimieren und wegschrieben würde erheblich länger dauern als einmal die Tebelle(n) komplett zu laden und zu durchlaufen.

Ich war der Meinung, man kann den Status beim .Active erfragen

[p80286]

Zitat:

Zitat von Sugar (Beitrag 1351649)

Mir ist natürlich klar, dass ich mit Queries arbeiten könnte, allerdings baue ich gerade keine userorientierte Oberfläche, sondern möchte Massenänderungen mit Userdialog durchführen. Jedesmal einen Datensatz zu selektieren, dannn zu prüfen, optimieren und wegschrieben würde erheblich länger dauern als einmal die Tebelle(n) komplett zu laden und zu durchlaufen.

?? "keine userorientierte Oberfläche" <> "Userdialog" ??

Wenn du größere Änderungen durchführen willst, dann könntest Du doch gleich SQL bemühen

SQL-Code:

 Update mytable set myfield='bubu' where myfield='baba';

Gruß
K-H