Interfaces "zwischenspeichern"

[MatthiasR]

Ich stehe aktuell vor folgendem Problem:

Ich arbeite mit den ZEOSLib Datenbankkomponenten und möchte mir gewisse Query-Ergebnismengen von verschiedenen Select-Befehlen zwischenspeichern, um später wieder darauf zurückgreifen zu können. Ich verwende eine Query-Komponente, die nach jedem Select-Befehl mir ein Resultat vom Interface "IZResultSet" zurück gibt.

Spontan hatte ich versucht mit einer TObjectList zu arbeiten, aber die nimmt ja nur Nachfahren von TObject auf und keine Interfaces. Und für jedes zwischenzuspeichernde Ergebnis ein eigenes Query-Objekt anzulegen, das ich dann in einer TObjectList speichere, kann doch auch nicht des Rätsels Lösung sein. Oder werde ich da gar nicht drum herum kommen? Kann ich die Ergebnisse überhaupt zwischenspeichern oder sind die beim nächsten Query.Open (also beim Absenden einer neuen Anfrage) mit den neuen Ergebnissen überschrieben (bin jetzt nicht soooo der Interface-Guru, daher weiß ich das gerade leider nicht).

[mkinzler]

Object -> TObjectList
Interface -> TInterfaceList

[MatthiasR]

:wall:
So einfach kann eine Lösung sein...

Ist nur die Frage, ob sich das "Objekt" hinter dem Interface ändert, wenn ich ein neues Select ausführe, aber das probiere ich nun einfach mal aus :-D .

[MatthiasR]

Scheint nicht so zu funktionieren, wie ich mir das vorgestellt hatte :( . Die alten Query-Ergebnisse werden bei neuen Select-Befehlen verworfen.

[shmia]

Haben alle Query-Ergebnisse die gleiche Struktur?
Falls ja, dann kannst du die Ergebnisse in ein Memory-Dataset kopieren.

[MatthiasR]

Leider nein. Die Strukturen unterscheiden sich jeweils, weil die Abfragen auf verschiedene Tabellen laufen.

Bleibt für mich der einzig gangbare Weg, jeweils ein eigenes Query-Objekt anzulegen. Nur stellt sich dann die Frage, wieviele gleichzeitig geöffnete Queries der PostgreSQL-Server bzw. auch der Rechner, auf dem das Programm später laufen soll, überhaupt verträgt. Was ist da so die Obergrenze von gleichzeitig aktiven Query-Objekten, wenn sich alle die gleiche Connection teilen würden?

[mjustin]

Zitat:

Zitat von Infect

Leider nein. Die Strukturen unterscheiden sich jeweils, weil die Abfragen auf verschiedene Tabellen laufen.

Bleibt für mich der einzig gangbare Weg, jeweils ein eigenes Query-Objekt anzulegen. Nur stellt sich dann die Frage, wieviele gleichzeitig geöffnete Queries der PostgreSQL-Server bzw. auch der Rechner, auf dem das Programm später laufen soll, überhaupt verträgt. Was ist da so die Obergrenze von gleichzeitig aktiven Query-Objekten, wenn sich alle die gleiche Connection teilen würden?

In diesem Fall (verschiedene Queries) würde ich zur Speicherung der Daten TClientDataSet verwenden je Query eines. Der Vorteil ist, dass nach dem Öffnen einer Query die Connection geschlossen werden kann, im ClientDataSet aber immer noch alle Datensätze stehen und daher 'offline' benutzt werden können.

Die Anzahl gleichzeitig verfügbarer Abfragen ist dann durch den Speicher des Client-Rechners begrenzt.