Hallo zusammen,

ich arbeite mit TUniDac und möchte in meiner Anwendung sicherstellen, dass beim Öffnen oder Aktualisieren eine größeren Tabelle die Anwendung nicht einfriert. Dazu habe diverse Artikel gelesen, wie Queries in einem Thread ausgeführt werden können. Ich habe vor, die Connection und die TUniQuery im Thread zu erzeugen. Wie aber übergebe ich die Ergebnismenge an meine Hauptanwendung so dass ich dort mit einer beliebigen Datenbankkomponente (Navigator, dbGrid, ...) darauf zugreifen kann. Die Ergebnismenge wird nur zur Navigation benötigt. Inserts und Edits werden über eine andere UniQuery abgearbeitet.

Bitte keine Ratschläge, dass ich meine SQL-Statements optimieren soll um die Zugriffszeiten herunter zu bekommen. Es geht mir auch ums prinzipielle Threadhandling.

Danke
Gerd

Du brauchst etwas wie ein ClientDataSet, MemTable, etc.

Die Daten holst du wie jetzt in einem Thread, kopierst die Daten in die MemTable und übergibst nun diese synchronisiert an die Oberfläche.

Dabei würde ich keine Instanz der MemTable in den Thread hineingeben, sondern beim Start der Abfrage die aktuelle MemTable entfernen und im Abfrage-Thread eine neue Instanz der MemTable erstellen.

Wenn das die Daten in einzelnen Paketen laden kannst (Pagination), dann würde sich das Problem so nicht stellen, denn dann zeigst Du die 1. Seite und würdest beim Scrollen einfach die nächste Seite laden. Aber das wolltest Du ja so nicht umsetzen, sondern prinzipiell die Vorgehensweise im Thread erklärt haben.

Bei der Pagination hat der Anwender keine Wartezeiten, beim vollständigen Laden der Daten hingegen schon. Denn warten muss der Anwender, aber entweder kann er den Vorgang abbrechen oder eben nicht.

Gut. Die Daten in einem Haps zu laden, hat Sir Rufo schon erklärt. Einige Provider unterstützen das asynchrone Laden von Daten. Der Provider lädt das Ergebnis dann in Stücken. Man gibt bei der Ausführung der Query einen 'Callback' an, der vom Provider dann zwischendurch aufgerufen wird. Nämlich immer dann, wenn der nächste Teil der Ergebnismenge zur Verfügung steht.

Ich weiß nicht, ob UniDac das unterstützt. Es wäre jedoch einen Versuch wert.

Wenn die Ergebnismenge jedoch nicht sonderlich hoch ist, und die Wartezeit aus der Komplexität der Query resultiert, dann muss man sich fragen, ob es sich lohnt, die Abarbeitung in einen Thread zu packen, denn bei einem Abbruch durch den Benutzer muss man ja auch in der Lage sein, die Query abzubrechen.

Vielleicht an dieser Stelle die Frage: Wieso dauert das lange? Komplexe Query oder viele Daten?

Zitat:

Bei der Pagination hat der Anwender keine Wartezeiten, beim vollständigen Laden der Daten hingegen schon.

Aber nur, wenn das Zusammenstellen der Daten schnell geht und nur die Übertragung einer großen Menge an Daten zum Clienten lange dauert.
Denn der Server stellt dabei bei sich die Daten erstmal komplett zusammen, vorallem wenn auch noch eine Sortierung enthalten ist und erst danach geht die Übertragung los.

Schneller geht es in jedem Fall. Ob es schnell geht, hängt wirklich von der Query ab.

Hallo zusammen,

danke für die Inputs. Bei den Daten handelt es sich um ca 1.2 Mio Datensätze. Das SQL sieht so aus:

SELECT ID, SerNr, Typ, Dat
FROM Ser_Nr
WHERE &ServOrt
ORDER BY SerNr, Dat

und stellt Daten für eine LookUp bereit. Das funktioniert auch, nur dass der Anwender je nach Arbeitsplatz 20-30s warten muss bis die Anwendung gestartet ist (Bei mir lokal dauert es ca. 3s). Und wenn das Laden der Daten in den Hintergrund verlegt werden kann, wäre das super. Ich habe auch schon mit dem Parameter Fetchall rum probiert. Dann wird das Starten zwar schneller, dafür wartet der Anwender aber beim Eingeben, da die Restdaten dann dort geladen werden.

Mit Virtualtable hatte ich bisher nicht gearbeitet, aber die Idee ist gut. Dann könnte ich auch hin und wieder im Hintergrund nachfragen ob auf dem Server neue Daten dazu gekommen sind und diese anfügen. Denn bei einem Refresh wartet der Anwender im Moment halt wieder.

Etwas erstaunt war ich als ich bei mir die Daten zuerst per

• UniQuery geöffnet habe (ca. 3s)
• und dann an über VirtualTable1.Assign(UniQuery) zugeordnet habe, was 18s dauerte

Ich habe leider keinen direkten Zugriff auf die langsamen Arbeitsplätze bei meinem Kunden, werde aber bei Gelegenheit schauen wie sich die Zeiten dort verhalten.

Gibt es einen schnelleren Weg von der DB in die VirtualTable?

Grüße
Gerd
: