Zwei Tabellen synchron halten?

[rebe]

Hallo iSeries-Freunde!

Mit welchen Befehlen oder Methoden kann ich denn zwei identische Tabellen synchron halten?

Die beiden Tabellen haben die gleichen Felder und sollen immer die gleichen Inhalte haben (annähernd zeitgleiche Synchronisation). Man könnte dafür drei Trigger (insert, delete, update) nehmen.
Was geht sonst noch?

Vielen Dank für Hinweise.

Grüße
rebe

[cbe]

sag doch mal kurz, warum Du 2 Tabellen brauchst?
(Die einfachste + sicherste Art eine Datei mit identischen Inhalt zu haben ist eine LF ;-)

[Fuerchau]

Da stimme ich cbe zu, die LF kann auch in einer anderen LIB mit Nurlese-Berechtigung stehen.

Ansonten gehts am schnellsten halt nur mit Triggern.

[rebe]

Hallo,

ja vielleicht hätte ich meine Anforderung komplett darlegen sollen.

Ich habe Dateien in einer Bibliothek A, auf die Public *exclude Rechte vergeben sind. Wir möchten die Rechte an diesen Dateien nicht aufweichen für die Anforderung, damit wir nicht den Überblick verlieren, wer auf die Dateien in dieser besonderen Bibliothek zugreifen kann.

Deshalb Idee, gleiche Datei in anderen Bibliothek mit *use Rechten. Log. Datei funktioniert nicht, wegen PUBLIC *exclude an der Bibliothek A und den physischen Dateien. Oder sehe ich das falsch?

rebe

[BenderD]

...wenn die Anforderung die Anforderung ist und nicht eine spezielle Lösung, ist diese Berechtigungslage leicht abzubilden (BTW: das enstspricht der Normalität in der Welt von SQL).
Einfach eine create view (kann auch in anderer Lib sein) und dann grant select to public auf diese View.

D*B

Hallo,

ja vielleicht hätte ich meine Anforderung komplett darlegen sollen.

Ich habe Dateien in einer Bibliothek A, auf die Public *exclude Rechte vergeben sind. Wir möchten die Rechte an diesen Dateien nicht aufweichen für die Anforderung, damit wir nicht den Überblick verlieren, wer auf die Dateien in dieser besonderen Bibliothek zugreifen kann.

Deshalb Idee, gleiche Datei in anderen Bibliothek mit *use Rechten. Log. Datei funktioniert nicht, wegen PUBLIC *exclude an der Bibliothek A und den physischen Dateien. Oder sehe ich das falsch?

rebe

[Fuerchau]

Das geht auch per DDS-LF.
Einfach eine LF in die andere Lib erstellen.
Wichtig ist nur, dass die Original-LIB auf *PUBLIC *EXCLUDE steht, die einzelnen PF's müssen mit *PUBLIC *READ autorisiert sein.
Datenrechte funktionieren nur auf einer PF. Selbst wenn ich eine LF (View) auf *USE stelle benötige ich Leserechte auf der PF.
Durch die Sperre der LIB komme ich dann aber trotzdem nicht auf die einzelnen Objekte der Lib.

Alternativ gibts halt Schutzsoftware wie PCSACC/400.

[BenderD]

... ich hatte hier extra SQL erwähnt, damit man es nicht falsch macht!
- die Berechtigung an der Bibliothek ist Banane
- an der Tabelle PF wird nur die Datenberechtigung eingetragen, also hier nur read
- alles andere ist für public verboten
- an der View braucht man die operational Berechtigung
- an der View braucht man die Datenberechtigung read

- CREATE TABLE mit naming *SQL macht den EXCLUDE
- der SQL grant Befehl für die View macht den Rest automatisch

PCSACC bringt hier wohl nix, bei RLA zieht kein exit.

D*B

Das geht auch per DDS-LF.
Einfach eine LF in die andere Lib erstellen.
Wichtig ist nur, dass die Original-LIB auf *PUBLIC *EXCLUDE steht, die einzelnen PF's müssen mit *PUBLIC *READ autorisiert sein.
Datenrechte funktionieren nur auf einer PF. Selbst wenn ich eine LF (View) auf *USE stelle benötige ich Leserechte auf der PF.
Durch die Sperre der LIB komme ich dann aber trotzdem nicht auf die einzelnen Objekte der Lib.

Alternativ gibts halt Schutzsoftware wie PCSACC/400.

[Fuerchau]

Das würde ich nicht dem H.Busch mitteilen, denn seit V5R4 gibts auch Exits für DB-Open (RLA), die von PCSACC nun auch überwacht werden können.

Die Berechtigung an der LIB kann durchaus mit Public-Exclude Sinn machen, um eben nicht an andere PF's/LF's o.ä. doch noch dranzukommen.

[BenderD]

... das mit den Exits ist doch sowieso an der falschen Stelle den Hals zugewürgt (ich habe mir jetzt nicht die Mühe gemacht, da noch nach CPYF und ähnlichen Lücken zu suchen), da wird zu 98 % eine unsachgemäße Objekt Security an der falschen Stelle nachgebessert...
Casus knaxus einer korrekten Installation ist, das an der PF keine Operational Berechtigung für public vergeben wird!

D*B

Das würde ich nicht dem H.Busch mitteilen, denn seit V5R4 gibts auch Exits für DB-Open (RLA), die von PCSACC nun auch überwacht werden können.

Die Berechtigung an der LIB kann durchaus mit Public-Exclude Sinn machen, um eben nicht an andere PF's/LF's o.ä. doch noch dranzukommen.

[rebe]

Hallo,

vielen Dank für eure Beiträge.

Da wir die Berechtigung an dieser bestimmten Bibliothek absolut nicht aufweichen möchten, damit wir irgendwann die Leseberechtigung für Daten an der physischen Datei (nicht am Objekt) nicht übersehen, werde ich zu den Triggern greifen.

Grüße
rebe

[BenderD]

... also wird hier wieder einmal, wie so oft, eine falsche Implementierung zur Anforderung gemacht und anschließend an der falschen Stelle versucht zu heilen...

D*B

Hallo,

vielen Dank für eure Beiträge.

Da wir die Berechtigung an dieser bestimmten Bibliothek absolut nicht aufweichen möchten, damit wir irgendwann die Leseberechtigung für Daten an der physischen Datei (nicht am Objekt) nicht übersehen, werde ich zu den Triggern greifen.

Grüße
rebe

[Fuerchau]

Mit aufweichen hat das wirklich nichts zu tun.
Von vornherein den schlechtesten Ansatz zu wählen halte ich auch für bedenklich.