SQL inner join

[Robi]

Hallo guten Morgen!

Ein Problem könnte noch die RRN-Funktion haben, da die ggf. nicht optimierbar ist oder den Dynamic-Cursor verhindert.

Wofür brauchst du die überhaupt ?

Na ja, das ist halt ein Pgm das mit den gelesenen Sätzen
und anderen Dateien ein bisserl rumrechnet und anschl. die Dateien updatet.
Da wir mit 'Lese und Schreib'-Programmen arbeiten (Es gibt keine F-Karte in den Programmen, zum lesen und schreiben wird ein Pgm gerufen) brauchen wir die Satznr. Die ist Basis für das Schreiben .

Du benötigst einen Dynamic-Scroll-Cursor.
Dann ist es aber wichtig, dass du für die On-Beziehung und Where-Klause die richtigen Zugriffspfade hast.

DECLARE C1 DYNAMIC SCROLL CURSOR FOR SEL_FLD
ist dann wohl das richtige

Zugriffspfade sind ok


Vielen Dank euch beiden

gruß
Robi

[Robi]

das Programm habe ich geändert und an den Kunden geschickt.
Heute kommt ne Meldung, das das programm imernoch Daten
zerstört (beim Update alte Sätze schreibt)
d.h. Das Pgm 'liest' immernoch den Inhalt der Datensätze zum Zeitpunkt des Open und nicht des Fetch

C/EXEC SQL
C+ DECLARE C1 DYNAMIC SCROLL CURSOR FOR SE_FLD
C/END-EXEC

fehlt mir noch was

@Fuerchau

Join's sind immer temporär (ggf. Kopie der Daten) und werden beim Open nicht beim Prepare ermittelt.
Du benötigst einen Dynamic-Scroll-Cursor.
Dann ist es aber wichtig, dass du für die On-Beziehung und Where-Klause die richtigen Zugriffspfade hast.

Immer Temporär ? dann geht das also nicht ? trozu dynamic-scroll-cursor ?

Danke
Robi

[BenderD]

Hallo,

der dynamic scroll cursor kann allenfalls sicher stellen, dass die Daten tatsächlich beim Fetch geholt werden (wobei man da nochmal in der Reference und bei der Wandlung genau nachsehen sollte, ob das auch so erstellt wird, oder per warning unterlassen wird). Was dann zwischen fetch und update passiert, steuert das commit level und was da genau unter blablabla zu verstehen ist.

mfg

Dieter Bender

das Programm habe ich geändert und an den Kunden geschickt.
Heute kommt ne Meldung, das das programm imernoch Daten
zerstört (beim Update alte Sätze schreibt)
d.h. Das Pgm 'liest' immernoch den Inhalt der Datensätze zum Zeitpunkt des Open und nicht des Fetch

C/EXEC SQL
C+ DECLARE C1 DYNAMIC SCROLL CURSOR FOR SE_FLD
C/END-EXEC

fehlt mir noch was

@Fuerchau

Join's sind immer temporär (ggf. Kopie der Daten) und werden beim Open nicht beim Prepare ermittelt.
Du benötigst einen Dynamic-Scroll-Cursor.
Dann ist es aber wichtig, dass du für die On-Beziehung und Where-Klause die richtigen Zugriffspfade hast.

Immer Temporär ? dann geht das also nicht ? trozu dynamic-scroll-cursor ?

Danke
Robi

[Fuerchau]

Ausserdem muss man noch bedenken, dass bei Joins ggf. auf Kopien zugegriffen wird (ALWCPYDTA), gibts auch irgend eine QAQQINI-Einstellung dafür.
Desweiteren wird beim Lesen auch häufig geblockt, so dass bereits mehrere Sätze im Puffer stehen, während andere "lustig" die Daten bereits verändern.

Das hat auch gar nichts mit SQL zu tun, sonder geschieht auch bei (ILE)RPG.
Verarbeite ich eine Datei sequentiell mit Input, kann ich für späteren Update nicht garantieren, dass die Daten noch korrekt sind.

Hierfür gibts das Konzpt der Satzsperren, so dass ich bei einer U-Datei den Satz vor Änderungen schütze.

Bei SQL geht das nur, wenn die Dateien journalisiert werden, da ich dann mit dem entsprechenden Commitlevel bereits beim Lesen sperren kann. Ansonsten erlaubt SQL (wie bei I-Dateien) jederzeit einen "Dirty"-Read !

Um also "alten" Schrott nicht zurückzuschreiben muss man entweder journalisieren, oder (so machts z.B. MS-Access automatisch):

update myfile set field=newval
where myfile.key=mykey and field=oldval

SQLCOD=0 bedeutet, Update erfolgreich, SQLCOD=100 bedeutet
a) Satz nicht mehr da oder
b) Oldval stimmt nicht mehr

Die RRN kann da eher tödlich werden, da diese je nach Methode inzwischen anders sein kann.
Es soll Anwendungen geben, die einen zu verändernden Satz vorher löschen und dann neu anlegen. Die RRN ist daher nie eine Garantie, dass diese hinterher auch wieder stimmt.