update auf eine "joined" logische Datei

[wilfried]

Hallo,
ich möchte ein SQL-Update auf eine LF-Datei machen. Die ist mittels Join aus zwei physischen Dateien aufgebaut.

Es kommt da ein SQL0150 ?
Was wäre eine Alternative zu diesem LF, den ich mit SQL bearbeiten kann?

DANKE

[B.Hauser]

Es ist und war noch nie möglich eine gejointe Datei zu ändern, unabhängig davon, ob man mit native I/O oder mit SQL arbeitet.

Du musst die zugrundeliegenden physischen Dateien einzeln updaten.

Wenn es eine JOINED View wäre, bestünde noch die Möglichkeit einen Instead Of Trigger dranzuhängen, in dem dann die Updates auf die einzelnen Dateien erfolgt.

Aber bei DDS beschriebenen logischen Dateien ist das nicht möglich.

Bwz. Du solltes i.a. auch darauf verzichten logische Dateien mit SQL anzusprechen, sondern entweder über die physischen Dateien oder Tabellen oder über eine View gehen

Birgitta

[wilfried]

Ok, vielen Dank.
Wilfried

[BenderD]

klare Empfehlungen von mir:
- grundsätzlich in der Applikation nur Views verwenden und diese nie ändern, kommt ein Feld hinzu, gibt es eine zusätzliche neue View.
- instead Trigger sind eine der wichtigsten Neuerungen von DB2/400 in den letzten Releases und sind hier das Mittel der Wahl.
Im Kern geht es dabei um Entkoppelung von Datenbank und Anwendung. Zieht man das konsequent durch (was auch kompletten Verzicht auf RLA bedeutet), kann man sehr viel am Datenbank Design weiterentwickeln, ohne dass die Anwendung das überhaupt merkt.

D*B

[GJV23]

was auch kompletten Verzicht auf RLA bedeutet

Was ist damit gemeint ?

[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