Cpyf vs SQL

[Robi]

Hi *all
um aus einem Echt System Daten in in ein Test System zu übernehmen (ca. 30 Dateien die alle einen identischen schlüssel haben + 3-4 Dateien die etwas komplexer zu handhaben sind) wollt ich fogendes machen:

SQL Script
delete from test/file1 where key = wert;
insert into test/file1 select * from echt/file1 where key = wert

das für jede Datei
Aufruf mit runsqlstm .

Nun gibt es das Problem, das in der Test ab und an die Dateien schon verändert sind, dann knallt das Script.

Also hab ich alles umgestellt. In einem CL lösche ich über QMQRY und kopiere via cpyf mit increl
der Wert ist eine Empfangsvariable

Das cpyf liest aber JEDEN Satz zum kopieren, selbst da, wo die PF mit einem passenden key versehen ist.

bei > 8 mio Datensätzen/datei ein Tagesjob.

Da hier niemand die SQL-Source ändern würde, ist ein sql insert mit Feldnamen 'suboptimal'

Kann ich CPYF überreden den Index zu verwenden?
Oder jede andere idee wilkommen

Gruß
Robi

[Fuerchau]

CPYF kann das leider nicht.
Ein Index wird nur dann verwendet, wenn die PF selber einen Index hat und INCREL dann auch noch passt.

Du solltest halt eher dafür sorgen, dass die Dateien vom Feldaufbau eben identisch sind bevor du anfängst zu kopieren, dann ist SQL auch schneller.

[Robi]

Danke aber ...

die PF hat den Index Feld1, Feld2 und Feld3
mein increl geht nur auf Feld1.

Der Index wird nicht verwendet. (mittlerweile V7R1)

@Dateien vorher gleich machen
leider haben hier mehrere Programmierer EINE Testumgebung
Wenn ich die von den Kollegen frisch geänderten Dateien mal eben für meine Zwecke zurückdrehe könnte es sein, das ich ne Menge Freunde verliere:confused:

Robi

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