OnNewRecord nicht aufgerufen

[himitsu]

Wie wäre es, wenn jemand auf die abwegige Idee käme, mal zu schauen, was da eigentlich gemacht wird?

* So manches DBMS bietet es serverseitig an, ein Logging zu aktivieren.
* oder eben im Client loggen

TFDBatchMove bietet paar entsprechende Property an. (LogFileAction und LogFileName)
sowie https://docwiki.embarcadero.com/RADS...AC)#Monitoring

[haentschman]

Hallöle...

Zitat:

definiert habe, dass der Standardwert 0 sein soll (KASSE_BOOLEAN ist ein Smallint).

...nur zur Info. Der Standard Wert gilt NUR für neue Datensätze. Nicht beim select alter Datensätze (vor der Änderung auf Standardwert) die noch NULL haben.

[TurboMagic]

Zitat von haentschman:

Hallöle...

Zitat:

definiert habe, dass der Standardwert 0 sein soll (KASSE_BOOLEAN ist ein Smallint).

...nur zur Info. Der Standard Wert gilt NUR für neue Datensätze. Nicht beim select alter Datensätze (vor der Änderung auf Standardwert) die noch NULL haben.

Das verstehe ich leider noch nicht ganz:

Beziehst du dich auf das Lesen oder das reinschreiben?

Mein Szenario ist ja, dass ich aus einer Datenbankdatei eine Zeile Lese (die betrffende Tabelle hat wirklich
nur eine Zeile), der Spalten fehlen, die in der Ziel DB-Datei neu hinzugekommen sind und die dort als "not NULL"
deklariert sind. So wie ich FBBatchMove eingestellt habe muss es aus der Ziel DB erstmal alle Sätze dieser
Tabelle löschen (falls es welche gibt). Der zu kopierende Datensatz muss also für die Ziel DB neu sein und damit
meiner Meinung nach dieser Default Wert reingeschrieben werden, da die QUelldaten ja dafür keinen Wert haben.

Oder wo liege ich da jetzt falsch?

Grüße
TurboMagic

[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

[himitsu]

Zitat von TurboMagic:

Zitat von haentschman:

Hallöle...

Zitat:

definiert habe, dass der Standardwert 0 sein soll (KASSE_BOOLEAN ist ein Smallint).

...nur zur Info. Der Standard Wert gilt NUR für neue Datensätze. Nicht beim select alter Datensätze (vor der Änderung auf Standardwert) die noch NULL haben.

Das verstehe ich leider noch nicht ganz

Wenn es in der Quelle NULL ist, dieses Feld dann auch explizit als NULL ins Ziel geschrieben wird, dann bleibt das auch NULL ... wäre doch grob fahrlässig, wenn sich die Daten beim Kopieren verändern.

Dagegen ein Neues Feld, welches es vorher noch nicht gab, und das nicht ans Ziel übergibt, es also nicht im INSERT vorkommt, da nimmt die DB dann das DEFAULT.

Zitat von himitsu:

Wenn im generierten "INSERT"-Statement explizit einem Feld NULL übergeben wird, dann wird bei den meisten DBMS auch NULL in die Tabelle geschrieben.
Der "DEFAULT"-Wert wird vom DBMS nur verwendet, wenn das Feld nicht im Statement vorkommt, oder dort explizit DEFAULT übergeben wird.

Ich weiß nicht, ob FieDAC, bzw. der TFDBatchMoveDataSetWriter Letzteres kann.
https://stackoverflow.com/questions/...default-values
...

[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