OnNewRecord nicht aufgerufen

[TurboMagic]

Hallo,

hat jemand eine Ahnung, warum mein per Code zugewiesener OnNewRecord Handler
im Ablauf des FireDAC BatchMove.Execute nie aufgerufen wird? Für keine der
zu kopierenden Tabellen. Daten werden aber kopiert.

Delphi-Quellcode:

FWriter : TFDBatchMoveSQLWriter;
...

constructor TDBCopy.Create;
begin
  inherited;

  ... 

  FWriter                := TFDBatchMoveSQLWriter.Create(FBatchMove);

  FBatchMove.Reader      := FReader;
  FBatchMove.Writer      := FWriter;

  OpenSQLConnection(FSourceSQLConnection, SourceDBName);
  OpenSQLConnection(FTargetSQLConnection, TargetDBName);

  FReader.Connection              := FSourceSQLConnection;
  FWriter.Connection              := FTargetSQLConnection;
  FWriter.FDDataSet.OnNewRecord   := OnNewRecord;
end;

procedure TDBCopy.OnNewRecord(DataSet: TDataSet);
begin
  // Code hier drin wird definitiv nicht aufgerufen...
end;

Woran könnte das liegen?

Grüße
TurboMagic

[Uwe Raabe]

Ein

Delphi-Quellcode:

TFDBatchMoveSQLWriter

legt keinen neuen Datensatz im DataSet an sondern führt ein SQL INSERT aus. Damit gibt es auch kein

Delphi-Quellcode:

OnNewRecord

.

[Uwe Raabe]

Nebenbei: Wenn du eine inhaltlich gleiche Frage an verschiedenen Stellen (DP, DP-EN, SO) stellst, wäre es schön das jeweils anzugeben. Dann kann man an den jeweiligen Stellen nachschauen ob schon jemand eine passende Antwort gegeben hat. Vielleicht reicht ja auch schon eine Stelle für die Frage um die Threads zum Thema zusammenzuhalten.

[TurboMagic]

Hallo,

danke für die Info und Sorry, dass ich nicht auf den anderen Post hingewiesen hatte.
Wenn ich dich richtig verstehe, dann sollte ich für den Writer keinen SQL Writer benutzen
sondern den DataSetWriter benutzen. Der müsste dann in dem Event mittels FieldByName auf die
Spalte zugreifen können.

In deinem anderen Ansatz mit OnWriteRecord hab' ich noch nicht wirklich verstanden gehabt wie
ich an die nötigen Details ran komme um den gewünschten Wert eintragen zu können.

Grüße
TurboMagic

[TurboMagic]

Ok, das reine austauschen der Typdeklaration auf den TFDBatchMoveDataSetWriter
(und anpassen des Create Aufrufes) hilft nich, da dieser Writer keine .TableName Eigenschaft hat.

Wie muss ich damit umgehen?
Muss ich dem ein eigenes DataSet zuweisen?
Falls ja was für eines und wie damit umgehen? Ich hab' bisher immer FDQuery Datasets benutzt.

Grüße
TurboMagic

PS: der Post in der EN DP ist hier:
https://en.delphipraxis.net/topic/10...-target-table/

[Uwe Raabe]

Du kannst dem TFDBatchMoveDataSetWriter ja ein TFDTable zuordnen - das hat dann wiederum ein Property TableName.

Allerdings sind das alles nur Hinweise. Konkret habe ich das selbst auch noch nicht probiert.

Wenn das NOT NULL Feld in der Datenbank einen Default-Wert hat oder über eine Sequenz gefüllt wird, dann sollte ein INSERT auch ohne einen Wert für dieses Feld gehen. In dem Fall wird das Feld im Server passend belegt.

Ich weiß ja auch nicht, mit welchem Wert du das Feld belegst, wenn du es in einem der Events beschreiben würdest. In dem Beispiel in der DP-EN wird es ja mit 0 vorbelegt - das könnte man auch direkt im Server so festlegen (siehe ALTER COLUMN: SET DEFAULT)

[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? :o

Grüße
TurboMagic