Firedac Query fetch all

[jobo]

Ich hatte diese FetchAll Geschichte eher für ein älteres Problem gehalten.
Wie auch immer, ich arbeite immer mit Where Clause und ich denke, das ist nicht unüblich. FetchAll sind für mich begrifflich sehr nahe an cursor Implementierungen,die sehr spezifisch (Herteller) sein können.
Jede Komponente macht es auch etwas anders, bei Ado sind es maxrecords oder so einfach als Attribut des Dataset.
Denen "goldenen" Weg bei Diredac kenne ich nicht.

Wenn Du Table "gewohnt" bist, musst Du Dich wohl an Query und Where Clause gewöhnen oder solltest zumindest. Das Öffnen einer großen Datenmenge auf dem Server erzeugt auch eine erhebliche Last, ohne dass alle Sätze übertragen werden. Das will man nicht, insbesondere nicht in Mehrbenutzerumgebungen. Sehr leicht verständlich, wenn man sich Umgebungen wie Facebook o.ä. anschaut. Da wird natürlich nicht eine ganze User Table geöffnet nur weil sich einer anmeldet.

[MES]

Hast ja recht. Deswegen grenze es ja ein:
query1.open('Select * from Artikelstam where Artikeltyp='P') -> ergibt eine Datenmenge von sagen wir mal größer 50. Durch die Rowsetsize werden die ersten 50 geladen.

Nun kommt eine 2 Query die ich öffnen will. Die hat so wenige Datensätze, dass sich eine "where" nicht lohnt (kleiner 50).

query2.open('Select * from Zahlungsbedingungen' ). Jetzt wird bei der Query1 die Rowsetsize automatisch verworfen und es werden alle Datensätze eingelesen.
Selbst wenn ich in der query2 auch ein "where" einbaue (über Parameter) bleibt das Ergebnis unverändert. Zum besseren Verständnis ein weiteres Beispiel: query2 sind Lagerorte auf denen dieser Artikel gelagert ist. Im oberen Grid navigiert man über die Artikel und im unteren Grid werden die Lagerorte angezeigt. Quasi Master/Detail. Kann man sich leich mit Rechungen/Positione etc. auch vorstellen.

Doch ob ich wie oben beschrieben oder die Querys wahllos zum Testen öffne - es erfolgt immer ein "Aushebeln" der Rowsetsize und ein fetch all der query1 ist die Folge. Selbst wenn die Querys in keinerlei Beziehungen zueinander stehen. Es sieht aus, als ob beim Öffnen der 2. Query ein "disconnect" stattfindet um die 2. Query zu connecten und bei dem erneuten Connect der 1. Querry ein fetch all stattfindet. IRRE.

[MES]

Tagesabschlussmeldung: Es scheint am Verbindungsmanager zu liegen. Diesen verwenden wir um aus einer Ini die Werte raus zu lesen(Typ Persistent).
Stellen wir die Connection ohne den Manger her(in der Entwickungsumgebung) ist alles ok. Es funktioniert auch sauber (also kein fetch all) wenn wir die Verbindung im Quellcode vornehmen. Juhuuuu!!!

Morgen wird intensiv getestet und geforscht - ich werde berichten.