TFDBatchMove mit AutoInc

[TurboMagic]

Hallo,

gegeben ein Delphi 11.2, eine Firebird Datenbank mit Tabellen die per
Generator automatisch erzeugte eindeutige Primärschlüssel haben und
jemanden der mit FDBatchMove noch nichts gemacht hat.

Wunsch: Kopieren von solchen Datensätzen in eine andere Datenbank.
Dort ist ja auf der gleichnamigen Tabelle aber auch ein Generator drauf.

Geht sowas? Wie kann man mit sowas umgehen?
Und was, wenn das Ziel nicht eine andere DB ist, sondern die selbe Tabelle?
Ich also nur eine Kopie eines Datensatzes machen will? Kann ich beim BatchMove
also Spalten aussparen? (wäre auch für nicht zu kopierende Spalten interessant)
Also sowas wie * aber ohne "Spalte4" und "Spalte7", so dass ich nicht alle zu
kopierenden Spalten angeben muss, was bei Strukturänderungen doof wäre.

Grüße
TurboMagic

[Olli73]

Ist das Autoinc_feld so angelegt:

create table t1 (id integer generated by default as identity primary key)

oder via Trigger + Generator?

Wie sieht im zweiten Fall der Trigger aus?

[TurboMagic]

Pwer Trigger und Generator.
Trigger sieht so aus:

Delphi-Quellcode:

CREATE TRIGGER BI_KASSE_BONKOPF_BON_ID FOR KASSE_BONKOPF
ACTIVE BEFORE 
  INSERT
POSITION 0
AS
BEGIN
  IF (NEW.BON_ID IS NULL) THEN
      NEW.BON_ID = GEN_ID(KASSE_BONKOPF_BON_ID_GEN, 1);
END^

Grüße
TurboMagic

[Olli73]

Wenn du immer einen neuen Key haben willst musst du entweder das Feld nicht übergeben, Null übergeben oder den Trigger so ändern, dass er nicht auf Null prüft.

[TurboMagic]

Danke schon Mal dafür.
Nur: wie kann ich beim Batch Move Spalten ausblenden?

[Uwe Raabe]

Wenn das ID-Feld in der Zieltabelle als Identity markiert ist, sollte es reichen das poIdentityInsert aus den BatchMove-Options zu entfernen:

Zitat:

When this option is selected, then insert/update of the destination identity columns is enabled.

[TurboMagic]

Hallo,

bin noch ganz neu bei der BatchMove Komponente.
Was bedeutet Zielfeld? Muss ich da irgendwie angeben in welche Spalten die Quelldaten sollen?
Wenn die den selben Namen wie die Quellspalten doch wohl eher nicht, oder?

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

Zitat von TurboMagic (Beitrag 1516533)

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

Daten per BatchMove übernehmen und dann ein

SQL-Code:

update tabelle set spalte = spalte * -1

hinterherschicken?

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

[Olli73]

TFDBatchMoveSQLWriter.FDDataSet.UpdateOptions.Chec kRequired ?

[TurboMagic]

Noch ein anderes Problem mit dem Ansatz:
wenn ich mal eines Tages diesen Datensatz tatsächlich kopiert bekomme, hat ja der Generator für den
primary key in dieser Tabelle dem neuen Satz einen neuen Wert generiert.

Nur wie bekomme ich den zurückgeliefert?
Ja, ich könnte einfach mittels select nach dem höchsten Datensatz fragen, aber wenn dann mal später
evtl. mehrere Leute auf die selbe DB zugreifen wird's schnell haarig...

[TurboMagic]

Zitat:

Zitat von Olli73 (Beitrag 1516630)

TFDBatchMoveSQLWriter.FDDataSet.UpdateOptions.Chec kRequired ?

Hallo,

eben erst gesehen, gleich getestet, gleich enttäuscht worden. :-(
Sorry!

Grüße

TurboMagic

[Olli73]

Dann musst du wohl mittels TBatchMove.OnWriteValue die Nulls zu Defaulftwert machen...

Aber bei TFDQuery klappt das mit chekRequired bei mir super. Bei mir war das Problem aber auch nicht ein Defaultwert, sondern die Vergabe der ID durch die DB.

[TurboMagic]

Hallo,

oh ich... ;-)
Ich bin einen Schritt weiter: ich hatte ja schon ein Event im Writer in dem ich für bestimmte Spalten
Werte vor dem Schreiben ändern bzw. setzen wollte. Auch für die Spalte die jetzt immer Ärger gemacht hatte.
Nur: dazu muss diese Spalte natürlich beim Reader im Select drin stehen! :oops: :wall:

Also zumindest für die Tabelle komme ich damit schon mal weiter.

Grüße
TurboMagic

[Uwe Raabe]

Die Connection muss den Parameter ExtendedMetaData auf True setzen, damit FireDAC den Default-Wert erkennt.

[TurboMagic]

Danke für den Hinweis!

[TurboMagic]

Tja, nur knallt es mit ExtendedMetadata jetzt woanders.
Da will ich per FieldByName(..).AsInteger den Wert einer als Smallint definrten Spalte
abrufen und bekomme eine Exception geworfen, dass er diese Spalte nicht als Integer abrufen kann.
Aber Smallint passt doch da rein und .AsSmallInt gibt's ja nicht...

Was nun?

[himitsu]

Das .AsXyz ist dem egal.

Ihm geht es um den Typ des Feldes,
also TSmallintField statt TIntegerField. :zwinker:

Hast du die Felder selbst erstellt, oder lässt du Sie erstellen?

[TurboMagic]

Ich hab' nix selbst erstellt. Einfach eine FDQuery und der einen select als SQL gesetzt...

[himitsu]

Dann sollte es ja eigentlich schon stimmen.
Was sagt denn FieldByName(..).ClassName ?

[TurboMagic]

TBooleanField. Als das ist's genau genommen sogar intendiert, nur: woher weiß er das?
Und das müsste ich ja dann jetzt überall umstellen...

[himitsu]

Zitat:

Woher?

Rate mal, wofür die Meta-Data da sind. :wink:

Zusatzinfos zu den Feldern: Originaler Name, bei mit AS imbenannt, QuellTabellenname, der genaue Typ, das Default uvm.

[TurboMagic]

Moment! Ich hab nirgends gesagt, dass das Boolean sein soll. Woher leitet der sich das ab?

[himitsu]

Achso, klang irgendwie so, als wenn es "eigentlich" so sei. (in der DB)

Nja, das DBMS sagt der Übertragung (Treiber) was es ist, im Delphi kommt es als was an (meistens Integer/Enum) und dann gibt es z.B. eine Übersetzungstabelle von DB-ÜbertragungsTyp zu Delphi-Typ (TFieldType/TDataType) und dann nochmal eine Übersetzung zur TField-Ableitung.
Eventuell nochmal spezielle Anpassungen z.B. am Typename aus den ExtendedInfos.
Und man kann die Zuordnung auch nochmal selbst überschreiben. (z.B. wenn es Probleme gibt, oder man es anders braucht)

[Uwe Raabe]

Wie heißt denn die Domain für die SmallInt Spalte?

Zitat:

Q3: How can I force FireDAC to recognize some field as boolean?
A: A boolean field may be created using a domain. The domain name must contain 'BOOL' substring. Also, add ExtendedMetadata=True parameter to your connection definition. For example:

CREATE DOMAIN T_BOOLEAN SMALLINT;
CREATE TABLE ... (
...
BOOLEAN_FIELD T_BOOLEAN,
...);

[TurboMagic]

Ok, die hat "Boolean" mit im DOmain Namen. Das erklärt jetzt das.

[himitsu]

Zitat:

Eventuell nochmal spezielle Anpassungen z.B. am Typename aus den ExtendedInfos.

Ohne ExtraInfos kommt nur der interne Typ bei raus
und Mit weiß FD nun, dass es eigentlich ein Boolean ist.