FireDAC Batchmove Oracle Mysql macht Probleme

[just beginner]

Das Feld MA_ID ist in beiden Tabellen als NOT NULL deklariert, aber ohne Defaultwert.
Die MA_ID der Quell Tabelle wird über einen externen Prozess vergeben, da habe ich keinen Einfluss drauf.
Ich habe in der Zieltabelle eine Defaultwert für MA_ID hinterlegt. Hilft auch nicht.

Ich muss anscheint Batchmove noch einige Parameter mitteilen. Leider ist die Hilfe in der IDE und im WIKI recht dürftig.

[jobo]

Zitat von just beginner:

Das Feld MA_ID ist in beiden Tabellen als NOT NULL deklariert, aber ohne Defaultwert.

Das ist nicht ungewöhnlich.

Zitat von just beginner:

Die MA_ID der Quell Tabelle wird über einen externen Prozess vergeben, da habe ich keinen Einfluss drauf.

Das ist ungewöhnlich. Kannst Du das genauer sagen, was das für ein "Externer Prozess" ist. Ich kann's mir ehrlich gesagt nicht vorstellen.

Aber egal, es geht ja primär darum:
Wenn in der Zieltabelle kein Mechanismus für die Vergabe eines PK Values vorgesehen ist, sollten bei einer vollständigen Übertragung der Quellwerte, also alle Spalten inkl. existierendem PK, am wenigsten Probleme auftauchen.

Und
Vielleicht gibt es auch einen reinen Append Mode statt AppendUpdate. Das wäre evtl. näher an dem was Du willst und ebenfalls weniger kritisch.

[just beginner]

Komisch,

wenn ich nur

Code:

FDBatchMove.Mode := dmAppend;

oder

Code:

FDBatchMove.Mode :=    dmDelete;

oder

Code:

FDBatchMove.Mode :=    dmUpdate;

Setzte läuft die Funktion so durch und macht auch was Sie soll.

Der Modi

Code:

FDBatchMove.Mode := dmAppendUpdate;

Gehrt nur wenn die Zieltabelle leer ist.

Dass verstehe ich nicht ?

Barum?

[jobo]

Ein Insert/Append ist technisch halt was anderes als ein Update oder ein AppendUpdate. Es ist ja kein Zufall, dass es die verschiedenen Modi gibt.
Ich kenne die Komponenten nicht, schätze Du musst Dich da noch etwas einlesen. Außerdem müsstest Du für Dein Verständnis dieser Datenübertragung von Tabelle A nach B auch wirklich etwas über die PK Technik in Erfahrung bringen, die dort verwendet wird. Das ist der Dreh und Angelpunkt für ein funktionierendes Update und auch für ein Insert nicht ganz unerheblich.
"ein externer Prozess" zur Vergabe der PK Werte ist als Verständnisgrundlage für die BatchMoveOperation wohl zu dürftig.
Wenn Du weißt, wie der Server die PK Werte der Tabelle handhabt und wenn Du herausgefunden hast, wie die Komponente mit diesen Gegebenheiten umgehen kann (Konfiguration BatchMove Optionen), lässt sich das sicher lösen.
Die Frage wäre auch, was Du wirklich brauchst. Ein Update ist viel "teurer" als ein Insert oder Append.

[just beginner]

Ich sehe nur wie die Quelltabelle aufgebaut ist da steht im Create skript:


CREATE TABLE MITARBEITER (
MI_ID CHAR (6) NOT NULL,
KOSTENSTELLE VARCHAR2 (7),
DATBIS DATE,
...
CONSTRAINT STMA_PK
PRIMARY KEY (MI_ID));

CREATE INDEX STMA_IDX ON
MITARBEITER(MI_ID, KOSTENSTELLE, NAME);

Was meinst Du ein Update ist zu teuer? Performance?

Ich könnten ja auch nur dmAppend gefolgt von dmUpdate und dann noch irgendwie die nicht mehr in der Quelltabelle vorhanden Einträge auch in der Zieltabelle löschen.
Aber das dauert bei ca. 100.000 Einträge recht lange. Dann kann ich auch gleich ohne Batchmove via TFDQuery und sql die Daten übertragen?
Oder verstehe ich das System nicht?

[jobo]

Die Quelltabelle ist relativ uninteressant.
Das Spannende ist die Definition dafür, wie der PK in der Zieltabelle entsteht.
Also Table DML Script prüfen, Trigger prüfen.
Im Zweifel einfach ausprobieren, einen Datensatz in die Zieltabelle schreiben, per SQL oder wie auch immer, mal mit PK, mal ohne und schauen was passiert. Gibt es Fehler? Welcher Wert wird im PK eingetragen, wenn Du selbst keinen angibst.

Update "teuer":
"teuer" in Bezug auf Ressourcenverbrauch, es geht nicht um € (naja indirekt auch doch wieder)
Ein Insert ist total simpel. Datensatz reinschreiben, PK Index aktualisieren, fertig
Bei einem Update muss gesucht und verglichen werden, das kostet Ressourcen.

[just beginner]

Die Zieltabelle ist gleich der Quelle aufgebaut nur als MySql:

CREATE TABLE MITARBEITER (
’MI_ID’ CHAR (6) NOT NULL,
’KOSTENSTELLE ’ CHAR (7),
’DATBIS ’ DATE,
...
CONSTRAINT STMA_PK
PRIMARY KEY (MI_ID)
INDEX ’STMA_IDX’ (’MI_ID’, ’KOSTENSTELLE’, ’NAME’));

Batchmove kopiert alle Wert der Tabelle also auch MI_ID (ist die eindeutige Personalnummer) von der Quelltabelle zur Zieltabelle wenn die Zieltabelle leer ist.
Nur wenn Daten schon vorhanden sind geht es mit dmAppendUpdate nicht. Es geht ja mit dmUpdate also muss das mit den PK ok sein?