Cpyf vs SQL

[Pikachu]

Vielleicht geht was mit CPYF ... MBROPT(*UPDADD).

[Robi]

Damit könnt ich mir das löschen sparen, das löschen ist aber
- nicht das Problem und
- nötig, da in der Test Umgebung weitere Sätze zu dem Vorfall entstanden sein können die nicht dem 'Echt'- Fall entsprechen.

Robi

[Fuerchau]

MBROPT(*UPDADD) wird dann insgesamt langsamer, da auf der Zieldatei erst ein Chain versucht wird um anschließend Update oder Write durchzuführen (was natürlich einen PF-Key voraussetzt).
Blocking kann dann gar nicht verwendet werden und am Lesen ändert sich dadurch auch nichts.

Hier muss man ggf. 2-Stufig vorgehen (besser per QMQRY als RUNSQLSTM):

1. insert/select in temporäre Datei per SQL
2. CPYF mit MAP/DROP ohne INCREL in Ziel

Achte darauf, dass FRCRATIO(*NONE) beim Ziel eingetragen ist, das erhöht die Geschwindigket beträchtlich.

[Robi]

1. insert/select in temporäre Datei per SQL
2. CPYF mit MAP/DROP ohne INCREL in Ziel

na das nenn ich doch mal ne Idee!
da hätt ich ja auch drauf kommen können ...
Danke
Das mach ich !!!

Gruß
Robi

[Pikachu]

Was ist denn genau das Problem? Beispiel?

[Fuerchau]

Beim

insert into file2
select * from file1
where ...

stirbt SQL, wenn die Definition der Spaltennamen und Haupttypen (Zeichen/Numerisch) nicht identisch sind, also Spalten fehlen oder eingefügt wurden.
In einer Entwicklungsumgebung kommt das nun schon mal vor.
Der CPYF ist für sowas gedacht, da per *MAP/*DROP insbesonders fehlende Felder ignoriert und Typanpassungen soweit möglich vorgenommen werden können.