TFDJSONDataSetsReader liefert immer das letzte DataSet

[Uwe Raabe]

Zitat von Kostas:

Das Problem ist, ich übergebe immer das gleiche Object "qry" eigentlich sollte das keine Problem sein, ist es jedoch.

Das ist genau das Problem! TFDJSONDataSetsWriter.ListAdd speichert die Instanz in der Liste. Die Umwandlung in JSON geschieht erst später. Aus diesem Grund musst du nicht nur jeweils eine separate FDQuery mitgeben, sondern diese müssen auch außerhalb deiner aktuellen Routine weiter existieren.

Zitat von Kostas:

Der Objectname "qry" wird als "Table Name" exportiert und nicht wie erwartet,
nach meiner Vorgabe über "TableName"

Code:

 <Table Name="qry" SourceName="KONTAKTE" SourceID="1" TabID="0" EnforceConstraints="False" MinimumCapacity="50">

Du liest das falsch: "Table" ist der XML-Tag und "Name" das Attribut. Es handelt sich hier um das interne Storage-Format der Klasse TFDDatSTable. Der von dir übergebene Name taucht an dieser Stelle gar nicht auf.

Zitat von Kostas:

Wenn ich jedoch für jede Query ein eigene TFDQuery verwende die auch jeweils einen anderen Namen hat, funktioniert das Auslesen einwandfrei.

Genau so war es auch gedacht.

Zitat von Kostas:

Wenn das TFDJSONDataSets erzeugt und noch kein DataSet per "TFDJSONDataSetsWriter.ListAdd" geschrieben wurde,
würde ich erwarten dass   TFDJSONDataSetsReader.GetListCount(FJSONDataSets) 0 zurückgibt.
Das ist nicht so, es kommt eine Exception dass kein DataSet vorhanden ist.

Das ist richtig! Ich empfehle einen Eintrag in quality.embarcadero.com

Zitat von Kostas:

Der erzeugte JSON Text ist zu geschwätzig. Meine fünf Tabellen habe ich als CSV exportiert, erste Zeile die Feldbezeichner und danach die Records.
Alle fünf Tabellen zusammen ergeben etwa 1300 Bytes. Exportiere ich aus den fünf Tabellen das JSON in ein File hat dieses File 15000 Bytes.
Dabei ist auffällig, zu jedem Feld bei jedem Record werden die Feldbezeichner mit exportiert. Auch weitere Daten werden exportiert. Z.B.
für jedes Feld werden stolze 17 Eigenschaften exportiert. Somit ist die eigentliche Stärke von JSON ausgehebelt wie ich finde.

Es gibt noch einen weiteren Nachteil: Dadurch, daß das interne Storage-Format übertragen wird, funktioniert das nur, wenn Sender und Empfänger mit derselben FireDAC-Version arbeiten. Das fällt insbesondere dann ins Gewicht, wenn man das JSON als externes, neutrales Speicherformat verwenden will. Das ist es hier nämlich nicht.

Allerdings ist das wohl kaum als Bug anzusehen. Allenfalls als ungeschickte Implementierung.