OnNewRecord nicht aufgerufen

[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
Hier werden ja mit einem Statement mehrere Records übergeben und somit stünde ein Feld immer im Statement, sobald es mindestens einmal einen Wert enthält. (also falls/da nicht jeder Datensatz einzeln übergeben würde)

Beim normalen Query.Post, lassen viele DB-Komponenten die Felder mit NULL weg, wenn sie das INSERT-Statement generieren.
PS: Bei uns werden im AfterInsert meistens die Default-Werte von der DB abgerufen und in die DataSet.Fields eingetragen, damit die Nutzer Default-Werte bereits im Programm sehen, während des Ausfüllens der restlichen Edits. (dort greift dann auch beim Insert nicht mehr das DEFAULT der Datenbank, da bereits Daten in den Feldern drin stehen)

[Delphi.Narium]

Wie wäre es denn mit simplen Datenbanktriggern? (Die kannste ja nach dem Befüllen der Tabellen wieder wegwerfen.)

SQL-Code:

CREATE TRIGGER TR_KASSE_EINSTELLUNGEN_BI FOR KASSE_EINSTELLUNGEN ACTIVE before insert POSITION 0 AS 
BEGIN
  if (NEW.DRAWBACK_CALCULATION is NULL) then NEW.DRAWBACK_CALCULATION = 0;
END

CREATE TRIGGER TR_KASSE_PRINTSETTINGS_BI FOR KASSE_PRINTSETTINGS ACTIVE before insert POSITION 0 AS 
BEGIN
  if (NEW.PRINT_SMALL_BONS is NULL) then NEW.PRINT_SMALL_BONS = 0;
END

Und das Schöne daran ist, es ist vollkommen wurscht, auf welchem Weg die Daten in die Datenbank kommen, werden Werte für andere Felder benötugt, einfach die Trigger anpassen.

Sinnvoll ist es übrigens, Spalten, für die keine Werte bekannt sind, nicht mit ins Insert zu packen, sondern sie von der Datenbank per Defaultwert und/oder Trigger befüllen zu lassen. Das sind nun mal halt Aufgaben, die Datenbanken von Haus aus können, egal ob die Daten über ein Delphiprogramm oder Flamerobin oder ISQL, oder welche Datenbanksoftware gerade genutzt wird, ... in die Datenbank kommen.

Da muss man sich nicht zwingend erstmal 'ne Software schreiben, die das dann "irgendwie" (hoffentlich verlässlich) übernimmt.

[TurboMagic]

Sobald ich die Zeit dazu finde muss ich mir das mit den Defaultwerten nochmal anschauen.
Evtl. hatte ich da einfach beim Testen noch was falsch gemacht im Ablauf.

[TurboMagic]

Hallo,

habe mir das mit dem not NULL nochmal angeschauen, bin aber verwundert, dass es nicht klappt.
Im Anhang ein Screenshot eines DB Verwaltungstools, der zeigt, dass ich genau vor dem Öffnen
DB Verbindungen der Reader und Writer des Batch Move mit dem Tool für diese not Null Spalte
definiert habe, dass der Standardwert 0 sein soll (KASSE_BOOLEAN ist ein Smallint).

Und ja, ich habe diese Änderung auch Compiliert (so nennt das Tool das).

=> warum bekomme ich trotzdem diese Exception?

Grüße
TurboMagic

[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

[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)

[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

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