Hallo,
wir haben das Phänomen, dass beim Öffnen einer FDQuery die Konfiguration der automatisch erstellten Felder fehlerhaft sind:
FireDAC
erkennt nicht, dass manche
Felder gejoint/kalkuliert sind.
Dies hat zur Folge, dass
alle Felder in .Fields als persistente Felder der Basistabelle angesehen werden, und bei einem .Post versucht wird,
diese Felder aus der Basistabelle zu aktualisieren, was in einem sofortigen Fehler resultiert.
Auszug aus der Log:
Zitat:
177
Query SELECT A.ARTIKEL_SPERRHINWEIS, LAST_INSERT_ID() AS id,
FROM liefdb2A
WHERE A.id = LAST_INSERT_ID()
177
Query ROLLBACK
Das Feld "ARTIKEL_SPERRHINWEIS" ist hierbei ein gejointes Feld, es existiert nicht in der Tabelle "liefdb2".
Die FDQuery wird mit einem Statement geöffnet, welches ein Subselect beinhaltet. Dies ist in unserer Philosophie essentiell aus bestimmten Gründen.
Das Statement sieht etwa so aus:
Code:
SELECT * FROM (SELECT
liefdb2.*,
artstamm.FARBE,
artstamm.SPERR_BENENNUNG,
artstamm.ARTIKEL_SPERRHINWEIS,
FROM liefdb2
LEFT JOIN artstamm ON liefdb2.sachnr = artstamm.sachnr
LEFT JOIN arts_mm ON liefdb2.sachnr = arts_mm.sachnr
) A ORDER BY ID
Nachvollzogen haben wir die falschen Informationen im FireDAC-Abfrageeditor. Dort kann man sich die erhaltene Struktur anzeigen lassen, siehe Screen "falsch1.jpg".
Dabei ist das Feld WERANL das letzte persistente Feld aus der Tabelle "liefdb2".
Das phänomenale hierbei ist, dass wenn man im besagten Screenshot "falsch1.jpg" das "LEFT" bei "LEFT JOIN artstamm" weglässt, es auf einmal richtig funktioniert, und die gejointen Felder richtig erkannt werden, siehe Screen "richtig2.jpg".
Lässt man wiederum das "ORDER BY ID" am Ende weg, funktioniert es
wiederum nicht, siehe Screen "falsch3.jpg".
Wir können uns dieses Verhalten nicht rational erklären, weshalb wir uns an das Forum wenden möchten.