View Full Version : Datei ohne eindeutigen Schlüssel mit SQL Cursor abarbeiten und updaten
dschroeder
20-06-14, 10:08
Hallo,
vielleicht weiß jemand, ob folgendes geht:
Ich habe eine Datei, die keinen eindeutigen Schlüssel hat und möchte diese Datei durchlesen und jeden Satz, den ich verarbeitet habe, updaten. Mit Record Level Access ist das ja kein Problem: Satz mit read lesen und sperren, Feldinhalt ändern und dann mit update speichern und die Sperre aufheben.
Geht das auch mit embedded SQL?
Kann ich einen cursor "for update" deklarieren? Falls ja: Wird der aktuelle Datensatz des Cursors, der mit fetch abgerufen wird, dann gesperrt?
Dieter
Mittels "for Update" wird beim fetch der Satz gesperrt.
Den update führt man dann mittels
update myfile set ...
where current of CursorName
durch.
Hallo.
Vor demselben "Problem" stehen wir / ich derzeit in c# ... weiss jemand für diese Sprache evtl. auch
eine Methode / Funktion ...
Gruß,
Ralf
dschroeder
20-06-14, 10:23
Vielen Dank Baldur. Das ist genau die Antwort, die ich brauchte.
Dieter
dschroeder
20-06-14, 10:26
Doch noch eine Nachfrage: Ich habe eben in einem älteren Beitrag gelesen, dass man bei einem "For Update" Cursor keinen sort angeben kann. Habe ich das richtig verstanden und falls ja, ist das immer noch so?
Dieter
Nun, bei ODBC/JDBC/OLEDB kommt man an den CursorNamen des Treibers meist nicht dran.
Beim "current of CursorName" muss dieser ja explizit angegeben werden.
Hier hilft nur tatsächlich ein UniqueKey für die Zieltabelle.
Ab V7R1 gibt es einen internen Index für die RRN().
Also
select rrn(myfile) as rrnnr, blabla ...
update myfile ... where rrn(myfile) = rrnnr
Vor V7 kann das schon mal eine etwas längere Aktion werden.
Eine Satzsperre erfolgt natürlich erst beim Update, nie beim Lesen.
... das ist (zumindest) für JDBC nicht korrekt. ResultSet hat updateXXX Methoden für Feldinhalte neu zu setzen und updateRow() nagelt das dann in den aktuellen Satz.
Das mit den Sperren ist komplett falsch: das ist alles per Commit Level einstellbar und ohne Commit ist bei einem updatable Cursor der aktuelle Satz, ähnlich wie bei Rekord Löffel Ekzem gesperrt.
D*B
BTW: positioned update bringt massiv Performance Vorteile.
Nun, bei ODBC/JDBC/OLEDB kommt man an den CursorNamen des Treibers meist nicht dran.
Beim "current of CursorName" muss dieser ja explizit angegeben werden.
Hier hilft nur tatsächlich ein UniqueKey für die Zieltabelle.
Ab V7R1 gibt es einen internen Index für die RRN().
Also
select rrn(myfile) as rrnnr, blabla ...
update myfile ... where rrn(myfile) = rrnnr
Vor V7 kann das schon mal eine etwas längere Aktion werden.
Eine Satzsperre erfolgt natürlich erst beim Update, nie beim Lesen.
Doch noch eine Nachfrage: Ich habe eben in einem älteren Beitrag gelesen, dass man bei einem "For Update" Cursor keinen sort angeben kann. Habe ich das richtig verstanden und falls ja, ist das immer noch so?
Ich kenne jetzt den Eintrag nicht, aber eigentlich ist es umgekehrt.
Ein Cursor ist normalerweise updatebar, wenn nur Spalten aus einer einzigen Datei angegeben wurden.
In einem solchen Fall ist die Angabe FOR UPDATE nicht erforderlich, auch wenn der Cursor (bzw. die Datensätze) mit WHERE CURRENT OF upgedated wird.
Sobald jedoch ORDER BY angegeben wurde ist der Cursor nicht mehr updatebar (READ ONLY), es sei den es würde FOR UPDATE OF hinzugefügt.
Birgitta
dschroeder
20-06-14, 14:05
OK, das ist dann ja noch besser. Dann kann ich sortierte Cursor ja auch updaten!
Vielen Dank.
Dieter
UpdateRow() bei Java ist gefährlich!
Java generiert einen SQL-Update:
update mytable set field=newvalue where field1=f1oldvalue and field2=f2oldvalue ...
Wenn in dem Resultset nicht alle Felder aufgeführt sind, die den Satz eindeutig identifizieren kann und wird es zu multiplen Updates kommen.
Ohne eine Deklaration "for update" wird beim Lesen keine Sperre gesetzt, da dies ja nicht erforderlich ist.
Mit "for update" bzw. enstsprechendem CommitLevel wird beim Lesen bereits gesperrt.
Arbeitet man (wie auf der AS/400 leider häufiger) ohne Commit und Journal, wird bei "for Update " die 1. Sperre gesetzt und beim "Update ... where " über einen 2. ODP die 2. Sperre angefordert, was ja nicht geht.
Nur beim "update ... current of CursorName" wird die Sperre des Selects verwendet.
Auch bei Java (und das gilt für alle ODBC/JDBC/OLEDB) kann ich den internen CursorNamen nicht erfragen, da der meist vom Treiber bzw. automatisch erst auf dem Server generiert wird.
Für Remote-SQL ist daher eigentlich Journalisierung, Transaktionssteuerung sowie ein Unique Key Vorschrift.