TFDBatchMove mit AutoInc

[Uwe Raabe]

Das ist korrekt. Wenn Name, Typ und Size übereinstimmen sollte das problemlos funktionieren.

Mit den ID-Feldern ist das aber etwas tricky. Im Idealfall erkennt FireDAC solche Felder automatisch und entfernt das pfUpdate in den ProviderFlags. Damit wird das Feld nicht in die DB geschrieben. Mit dem Entfernen des oben genannten poIdentityInsert wird genau das ausgenutzt.

Näheres zu solchen ID-Feldern und deren Erkennung findest du hier: Auto-Incremental Fields

[TurboMagic]

Danke schon mal dafür, nur hab' ich ja noch ein Problem:
Ich muss auch ein paar der Spalten-Werte vor dem Schreiben negieren (* -1).
Das scheint so nicht wirklich machbar, zumidnest nicht was ich bisher so in
den Eigenschaften der Komponenten gesehen habe.

=> vermutlich muss ich's doch "klassisch" umsetzen.

[Delphi.Narium]

Zitat von TurboMagic:

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

Daten per BatchMove übernehmen und dann ein update tabelle set spalte = spalte * -1 hinterherschicken?

[Uwe Raabe]

Zitat von TurboMagic:

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

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