Tabellenabgleich ist sowas möglich?

[Fuerchau]

Egal ob du SQL oder eine Programm nimmst, schreiben musst du irgendwas.
Ein Programm ist da schon einfacher, da du hier Datenstrukturen vergleichen kannst, in SQL nur einzelne Felder.

Also im Prinzip folgendes:
Änderungen/Löschungen
lesen Datei1 in Struktur1
Chain Datei2 in Struktur2
%notfound => delete
struktur1 <> struktur2 => move Struktur2 nach Struktur1 und Update

Neu
Lesen Datei2
chain Datei1
&notfound => write Datei2

[firestone]

Danke für die schnelle Antwort.

Also von der Struktur her sind die Tabellen auf jeden Fall zu 100 % gleich nur der Inhalt kann abweichen.

Das Programm müsste folgendes leisten
Neue Sätze einfügen
geänderte Sätze updaten
und Sätze die nicht mehr vorhanden sind löschen

Wäre sowas über SQL Tatsächlich schwerer ?

[Fuerchau]

SQL kennt keine Datenstrukturen, du müsstes also einen Feld-für-Feld-Vergleich kodieren.

Um also SQL-Routinen zu stricken benötigst du 3 verschiedene SQL's mit dem Nachteil, dass du die Daten eben 3 Mal bearbeiten musst.

Im RPG benötigst du nur 2 Läufe, da der Update/Delete in einem Lauf möglich ist, der Insert im 2. Lauf.

Der Insert ist in SQL noch am einfachsten:

insert into dateiA A
select * from DateiB B
where not exists (select * from DateiA C where c.key = B.key)

Der Update wird dann schon schwieriger:

update DateiA A
set a.f1=(select b.f1 from dateiB where a.key = b.key and a.f1 <> b.f1)
,a.f2=(select b.f2 from dateiB where a.key = b.key and a.f2 <> b.f2)
,....
where exists (select * from dateiB b where a.key=b.key)

Wobei dieser SQL ab V5R4 auch etwas vereinfacht werden kann:

Update DateiA A
set (F1, F2, ...) = (select f1, f2, ... from DateiB b where a.key=b.key and (a.f1 <> b.f1 or a.f2 <> b.f2 .....))
where exists (select * from dateiB b where a.key=b.key)

Und zum Schluss der Delete:
delete from dateiA A
where not exists (select * from DateiB B where B.key = a.key)

[Robi]

Alternativ kannst du einer Trigger auf die Datei in der führenden Lib legen und diesen die Datei in der 2. Lib updaten lassen.
Vorteil: top aktuell, keine stündlichen Performanceeinbrüche.
Nachteil: warscheinlich fest verdrahtete Lib's
Gruß
Robi

[andreaspr@aon.at]

Nur als Info falls es wem interessiert:
ab IBM i 7.1 gibt es die Merge-Funktion in SQL.
Mit der kannst du z.B. ein Update/Insert in einer SQL-Anweisung absetzen.

merge into tab1                                     
using tab11                
on tab1.sp1 = tab11.sp1                             
when matched then                                   
     update set tab1.sp2 = tab11.sp2                
when not matched then                               
     insert (sp1, sp2) values (tab11.sp1, tab11.sp2)

[firestone]

Super danke für die Antworten habe jetzt eine Lösung für mich gefunden die passt

[BenderD]

... wieder mal Sumpf, was gibt es für einen Grund, dass eine Tabelle zweimal existiert, wenn eine davon führend ist???

D*B

[Pikachu]

Vielleicht ne Testumgebung die alle Stunde auf den aktuellen Stand gebracht werden soll.

[BenderD]

... zieht auch von unten an den Füssen:
- Echtdaten sind keine Testdaten (Datenschutz, enthalten zuwenig Grenzfälle, gewährleisten keine Testabdeckung)
- Testdaten die nebenläufig überklotzt werden, na toll???

D*B

Vielleicht ne Testumgebung die alle Stunde auf den aktuellen Stand gebracht werden soll.

[Fuerchau]

Nunja, und was die Performance angeht wäre ein CPYF mit Replace wohl die schnellste Möglichkeit.

[BenderD]

... ist doch warm heute, dann dürfte die Tabelle nicht benutzt werden, dann braucht man den CPYF auch nicht!!!

D*B

Nunja, und was die Performance angeht wäre ein CPYF mit Replace wohl die schnellste Möglichkeit.

[Fuerchau]

CPYF würde gehen, wenn die Zieltabelle frei ist. Der erschlägt alles, Update, Insert, Delete.

Trigger wären am effektivsten, wobei man ggf. ab und an den CPYF benötigte.