SQL inner join

[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.