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.
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.
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.
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
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.