OnNewRecord nicht aufgerufen

[TurboMagic]

Hallo,

hab' jetzt mal so ein Protokoll anfertigen lassen, nur hat mir das auch nicht mehr gesagt als das, was ich schon wusste
Es ist auch recht platzverschwednerisch formatiert und wo da keine Fehler gefunden wurden wird auch nicht klar, weil die
Leider keinen Tabellennamen reingeschrieben haben. Aber ja, nicht alles ist eine Tabelle für Batch Move.

Hier der relevante Teil des Logs in der originalen Formatierung:

Code:

*************** Protokoll starten 03.12.2023 10:17:04 ***************

          **********  Keine Fehler protokolliert **********

*************** Protokoll beenden 03.12.2023 10:17:04 ***************



*************** Protokoll starten 03.12.2023 10:17:04 ***************

[FireDAC][Phys][FB]validation error for column "KASSE_EINSTELLUNGEN"."DRAWBACK_CALCULATION", value "*** null ***"

INSERT INTO KASSE_EINSTELLUNGEN
(PWD, IS_LOCKED, INIT_WIZARD_RUN, CAN_SKIP_TSE, DRAWBACK_CALCULATION)
VALUES (:PWD, :IS_LOCKED, :INIT_WIZARD_RUN, :CAN_SKIP_TSE, :DRAWBACK_CALCULATION)

*************** Protokoll beenden 03.12.2023 10:17:07 ***************



*************** Protokoll starten 03.12.2023 10:17:07 ***************

          **********  Keine Fehler protokolliert **********

*************** Protokoll beenden 03.12.2023 10:17:07 ***************

Grüße
TurboMagic

[Delphi.Narium]

Soweit ich weiß, vergibt die Datenbank den Defaultwert nur dann, wenn eine Spalte im Insert nicht angegeben wird.

Wenn also DRAWBACK_CALCULATION Not Null ist und Du keinen Wert dafür hast, dann darfst Du für DRAWBACK_CALCULATION auch nicht im Insert Null übergeben. Beim Weglassen der Spalte im Insert übernimmt das dann die Datenbank, indem der Defaultwert in DRAWBACK_CALCULATION geschrieben wird.

SQL-Code:

INSERT INTO KASSE_EINSTELLUNGEN
(PWD, IS_LOCKED, INIT_WIZARD_RUN, CAN_SKIP_TSE)
VALUES (:PWD, :IS_LOCKED, :INIT_WIZARD_RUN, :CAN_SKIP_TSE)

[TurboMagic]

Hallo,

1. In der Quell DB gibt's die entsprechende Spalte noch gar nicht.
Was FireDAC beim Einfügen damit anstellt kann ich jedoch mangels Quellcode in der
Pro Version nicht nachschauen.

2. Somit habt ihr alle irgendwie recht, auch wenn mir das nicht so ganz hilft. Aber:

3. Ich habe jetzt eine funktionierende Lösung!
Der Hinweis von Uwe, dass TFDTable das OnNewRecord event aufruft und ich statt eines
SQL Writers einfach einen DatasetWriter mit zugewiesenem TFDTable benutzen könnte
hat zum Erfolg geführt. Im OnNewRecord prüfe ich jetzt, ob die entsprechende Spalte
der entsprechenden Tabelle NULL ist und falls ja, weise ich den Defaultwert zu.

Jetzt muss ich nur noch den Code ein wenig aufräumen, weil das ja bisher nur testweise
kurz eingebaut wurde.

Grüße
TurboMagic

[himitsu]

Wenn nun für das INSERT ein TFDTable genutzt wird, und das beim INSERT-Statement dann die NULL-Felder weg lässt, dann sollte doch direkt das DBMS den DEFAULT benutzen?

Oder geht vielleicht auch ein TFDQuery?

[Uwe Raabe]

Mit dem TFDBatchMoveSQLWriter würde es auch gehen, wenn du dessen WriteSQL Property bei jeder der betroffenen Tabelle passend angeben würdest. Bleibt das Property leer wird ein SQL automatisch erzeugt. Dabei werden die NOT NULL Felder als required erkannt und in das INSERT aufgenommen, was eine Zuweisung zu dem Feldwert erzwingt.

[TurboMagic]

Zitat von Uwe Raabe:

Mit dem TFDBatchMoveSQLWriter würde es auch gehen, wenn du dessen WriteSQL Property bei jeder der betroffenen Tabelle passend angeben würdest. Bleibt das Property leer wird ein SQL automatisch erzeugt. Dabei werden die NOT NULL Felder als required erkannt und in das INSERT aufgenommen, was eine Zuweisung zu dem Feldwert erzwingt.

Ja, das würde natürlich gehen und war mir auch bewußt.
Nur: dann ist ja der "Gag" weg, dass einem das System was automatisch abnimmt
Zumindest für Spalten die nicht als "not Null" deklariert sind. Man müsste dann nämlich bei jeder Änderung
das SQL anpassen, sonst fehlen die Daten nach dem Update

[Uwe Raabe]

Zitat von TurboMagic:

Nur: dann ist ja der "Gag" weg, dass einem das System was automatisch abnimmt
Zumindest für Spalten die nicht als "not Null" deklariert sind. Man müsste dann nämlich bei jeder Änderung
das SQL anpassen, sonst fehlen die Daten nach dem Update

In diesem Fall geht es ja nicht generell um die NOT NULL Spalten, sondern um die nicht im Source enthaltenen, im Target aber als required deklarierten. Genau diese Fälle versuchst du ja jetzt in dem Event abzudecken und auch da muss dann bei Änderungen entsprechend reagiert werden.

Eine weitere Alternative wäre übrigens das Anlegen eines Mappings mit dem Namen der Target-Column als DestinationFieldName und dem Defaultwert als SourceExpression, während SourceFieldName natürlich leer bleiben muss. Aber auch dass muss gegebenenfalls per Tabelle definiert werden.

Du musst halt schauen, welcher Ansatz den besten Mix aus Performance und geringem Maintenance-Aufwand bietet.

[himitsu]

Leider beachten viele DB-Komponenten nur das NOT NULL, aber kennen kein DEFAULT,
drum wollen sie zwanghaft bei "Required" (NOT NULL) etwas übergeben, bzw. werfen bösartig im BeforePost gern eine Exception.

JA, bei Required / NOT NULL muß letztendlich ein Wert vorhanden sein, aber der darf auch aus einem DEFAULT kommen.

[haentschman]

Moin...😎

Zitat:

...und das nicht ans Ziel übergibt, es also nicht im INSERT vorkommt, da nimmt die DB dann das DEFAULT.

...richtig.