update auf eine "joined" logische Datei

[BenderD]

RLA := record level access
sprich: keine F Bestimmungen, kein setll, chain, read und co.

D*B

[GJV23]

Danke, habe verstanden,

GJV23

[dibe]

Darf ich nochmal nachfragen ...

Dateien miteinamder verknüpfen als View, dabei Felder angeben und nicht * (= alle) verwenden!
In den Programmen mit SQL die View lesen.
Muß ein Pgm ein Feld eines oder mehrerer PF der View ändern, mach ich im Pgm

Update view set Feld = wert where "eindeutige identifikation des View-Satzes" ...

(oder geht der update ohne selektion da der Satz ja vorher gelesen wurde? --> Bsp?)

Und ein Trigger, der mit SQL geschrieben ist macht dann den 'echten' update in das PF?

Leider finde ich dafür kein Bsp im Netz, hat jemand einen link für mich?
Bsp f.
- instead Trigger (source Code)
- wie werden die an/ab gehängt
- hängen die an der View oder doch am PF?

Springt ein 'normaler' Trigger auch noch an, wenn der SQLTrigger die PF ändert/schreibt?

vielen Dank
DiBe

[BenderD]

Darf ich nochmal nachfragen ...

Dateien miteinamder verknüpfen als View, dabei Felder angeben und nicht * (= alle) verwenden!
In den Programmen mit SQL die View lesen.
Muß ein Pgm ein Feld eines oder mehrerer PF der View ändern, mach ich im Pgm

Update view set Feld = wert where "eindeutige identifikation des View-Satzes" ...

(oder geht der update ohne selektion da der Satz ja vorher gelesen wurde? --> Bsp?)

Und ein Trigger, der mit SQL geschrieben ist macht dann den 'echten' update in das PF?

Leider finde ich dafür kein Bsp im Netz, hat jemand einen link für mich?
Bsp f.
- instead Trigger (source Code)
- wie werden die an/ab gehängt
- hängen die an der View oder doch am PF?

Springt ein 'normaler' Trigger auch noch an, wenn der SQLTrigger die PF ändert/schreibt?

vielen Dank
DiBe

- normales create view as select mit oder ohne *
- create instead of trigger in https://www.google.de/url?sa=t&rct=j...7Xcja8T5-KXauU
- positioned update (mit where current of) oder searched update mit echter where clause
- der trigger muss dann die Daten auf die Basistabellen verteilen etc.
- trigger auf den unterliegenden PF werden ausgeführt.

D*B

[dibe]

Vielen Dank!
Wenn ich mich doch für * = alle Felder entscheide, dann passt Ihr Wunsch: "View nie ändern" aber nicht mehr!
Und der verweis auf das Red Book ...
heiß unterm Strich das wir SQL programmieren lernen müssen?
Bisher reichte uns ein ein bischen
select
updat
delete
set
mit verschiedenen "Join" oder mal ein "With" davor.
Schade, dann wird das wohl noch dauern.
Danke

[BenderD]

Vielen Dank!
Wenn ich mich doch für * = alle Felder entscheide, dann passt Ihr Wunsch: "View nie ändern" aber nicht mehr!

Das hängt davon ab, worauf sich der Stern bezieht.
z.B.:
create table kunde ....;
create view kundeV1 as select * from kunde;
create view select k.*, ... from kundeV1,

zusätzliches Feld für Kunde:
alter table kunde add column...;
kundev1 anpassen;
create view kundeV2 as select * from kunde;
...

Die SQL Programnierung kann man begrenzt halten, Es genügt ein einfacher wrapper für den SQL Trigger, der sofort ein externes (RPG) Programm aufruft, das die eigentliche Arbeit macht. Das hat der durchschnittliche Programmierer in einem Tag drauf.

Join und/oder with (ist eh' meist ein Zeichen dafür, dass das view layer nix taugt) wird man darin ohnehin nicht finden.

D*B