TFDBatchMove mit AutoInc

[Uwe Raabe]

Zitat:

Zitat von TurboMagic (Beitrag 1516533)

Ich muss auch ein paar der Spalten-Werte vor dem Schreiben negieren (* -1).

Delphi-Quellcode:

TBatchMove.OnWriteValue

:

Zitat:

The OnWriteValue event is triggered before a source value will be moved to target data source. The AItem argument identifies data item (eg, dataset field). The AValue argument represent the item value. An application may use this event to reformat or convert the source value.

[TurboMagic]

Halloo,

danke für den Hinweis, beim versuch da was drauß zu machen bin ich aber an einer anderen Stelle hängen geblieben.

Gegeben:

Delphi-Quellcode:

var
  FQueryReadKasseBonkopf : TFDBatchMoveSQLReader; 
  FBatchMoveBonKopf      : TFDBatchMove;
begin
  FQueryReadKasseBonkopf   := TFDBatchMoveSQLReader.Create(nil);
  FBatchMoveBonKopf        := TFDBatchMove.Create(nil);
  FBatchMoveBonKopf.Reader := FQueryReadKasseBonkopf;

  FQueryReadKasseBonkopf.ReadSQL :=
    'select KASSE_ID, BON_TYP, BON_NAME, BON_START, BON_ENDE, UMS_BRUTTO, ' +
    '       KUNDE_TYP, KUNDE_ID ' +
    'from KASSE_BONKOPF where BON_NR = :pBonNr';

  FQueryReadKasseBonkopf.FDDataSet.ParamByName('pBonNr').AsInteger := 123;
  FBatchMoveBonKopf.Execute;

Beim Ausführen der vorletzten Zeile kracht es mit "Parameter pBonNr" nicht gefunden.
Warum?

Natürlich ist das nicht alles so in einer Methode oder so, also Vorschläge direkt
das SQL anzupassen sind nicht wirklich zielführend.

[Uwe Raabe]

Das ReadSQL wird erst beim Open dem SQL des DataSets zugewiesen. Daher ist der Parameter zu dem Zeitpunkt noch nicht bekannt. In dem Fall wäre es vielleicht besser einen TFDBatchMoveDataSetReader und eine TFDQuery zu verwenden. TFDBatchMoveSQLReader unterstützt leider keine Parameter, sondern nur plain SQL.

[TurboMagic]

So, mit den Hinweisen bin ich einen halben Schritt weiter, nur kracht es jetzt anderweitig.

First chance exception at $7720E292. Exception class EIBNativeException with message
'[FireDAC][Phys][FB]validation error for column "MEINE_TABELLE"."MEINE_SPALTE", value "*** null ***"'. Process MeineExe.exe (6728)

Naja, diese MEINE_SPALTE existiert in der Quell und Zieltabelle, weil beide dieselbe Tabelle in der selben DB sind.
Diese ist als Nicht Null definiert, aber mit einem Default Value 0 und wird im SQL zum lesen des zu kopierenden Datensatzes
nicht mit ausgelesen, weil der Inhalt nicht kopiert werden soll.

Warum versucht da jetzt jemand NULL reinzuschreiben, statt einfach den Default Wert zu benutzen?
Wie kann ich das verhindern/ändern?

Die Optiones der BatchMove instance sehen übrigens so aus:
[poSkipUnmatchedDestFields];

Grüße
TurboMagic

[himitsu]

Wenn im INSERT das explizit als NULL zugewiesen wird, dann wird der DEFAULT nicht benutzt. Der wird nur verwendet, wenn diese Spalte garnicht übergeben wurde.

Bei manchen DBMS kann man auch im INSERT das Keyword DEFAULT als Wert angeben, wenn man diese Spalte unbedingt mit übergeben will/muß. (z.B. beim BatchImport/MultiInsert)
Notfalls könntest du im Batch-Script eventuell einfach alle NULL durch DEFAULT ersetzen.
(aber k.A. ob Firebird das auch so kennt)

Zitat:

poSkipUnmatchedDestFields

Eventuell ein Bug?
Aber sollte poSkipUnmatchedDestFields nicht nur "nichtvorhandene" Felder weglassen?
Bei dir existiert sie auf beiden Seiten, also ist sie somit matched (nicht unmatched).

[TurboMagic]

Danke mal dafür, nur: im SQL Statement für das Lesen steht diese Spalte ja gar nicht drin, ist also als Quelle nicht vorhanden
und der Writer für den BatchMove erzeuge ich zwar, gebe dem aber kein SQL vor. Das soll er sich ja selber zusammen bauen.

=> was nun?

Ich neige gerade dazu das wieder alles händisch ohne BatchMove zu machen, aber eigentlich wollte ich an der Stelle auch mal
das BatchMove ausprobieren... :-(

[Olli73]

Hast du irgendwo UpdateOptions als Eigenschaft?

Dann setz dort mal CheckRequired auf false (FireDAC.Stan.Option.TFDUpdateOptions.CheckRequire d).

[TurboMagic]

Hallo,

so eine Eigenschaft hab' ich nicht wirklich gefunden auer an der DB-Connection,
das ist aber nicht was du suchtest.

Der Write für die FDBatchMove Instanz ist ein TFDBatckMoveSQLWriter und da gibt's
sowas auch nicht. Die Options die der hat sind etwas anders gelagert...

Grüße
TurboMagic

[Olli73]

Wir nutzen das auch nur bei TfdQuery. Aber ich würde mal das bei der Connection probieren...

[TurboMagic]

Zitat:

Zitat von Olli73 (Beitrag 1516626)

Wir nutzen das auch nur bei TfdQuery. Aber ich würde mal das bei der Connection probieren...

Hab' ich eben, kracht aber leider genauso... :-(
Also immer noch die Frage wem ich in dem Szenario wie sagen kann, dass er diese Spalten in Ruhe lassen soll...
Passende QP reports hab' ich dazu auch nicht gefunden.