View Full Version : SQL + Datensatzsperre
Hi *all
wenn ich im RPG SQL verwende, um einen update zu machen
c/exec sql
c+ update datei set feld = wert where ...
c/end-exec
und in der Datei ein Satz gelockt ist, bricht SQL ab.
Ich habe zwar eine Msg im Joblog, sonst aber nix.
Ist der 1. Satz gelockt wird gar kein Update ausgeführt.
Kann ich SQL
a) gesprächiger machen um den Lock zu melden
b) veranlassen weiter zu machen und nicht einfach aufzuhören
Danke
Robi
... works as designed, ohne Commit Steuerung geht da (fast) nix ohne das Prinzip Hoffnung.
@a: da gibt es doch einen SQLCODE, diagnostics und noch Meldungen im Joblog, was soll die arme Datenbank denn noch machen?
@b: SQL denkt Transaktions orientiert und eine Transaktion ist nie kleiner als eine Anforderung und die kriegt er hier nicht hin und erwartet, dass man mit Rollback aufräumt. Wenn man das nicht kann oder will, bleibt eben Ramsch in der Datenbank zurück.
Wer updates mit SQL ohne Commit Steuerung macht, solllte mit dem SQL Handbuch erschlagen werden, oder eine Schulung verordnet bekommen.
D*B
Hi *all
wenn ich im RPG SQL verwende, um einen update zu machen
c/exec sql
c+ update datei set feld = wert where ...
c/end-exec
und in der Datei ein Satz gelockt ist, bricht SQL ab.
Ich habe zwar eine Msg im Joblog, sonst aber nix.
Ist der 1. Satz gelockt wird gar kein Update ausgeführt.
Kann ich SQL
a) gesprächiger machen um den Lock zu melden
b) veranlassen weiter zu machen und nicht einfach aufzuhören
Danke
Robi
Bitte nicht erschlagen ...
Soweit ich weis geht commit/rollback nur bei Journalisierung.
Wustest du nicht, das das die Maschine sooooooooooo langsam macht ? :rolleyes:
(Jedenfals bei meinen Kunden )
ok, kein Sql mehr
Danke
Robi
Nun ja, ganz so hart würde ich das auch nicht sehen.
Nach jeder SQL-Operation ist es wichtig, den SQLCOD (ILE = SQLCODE) abzufragen:
SQLCOD < *zero => meist schwerer Fehler
SQLCOD = *ZERO => alles OK
SQLCOD > *zero => Warnhinweise (z.B. 100 = EOF)
Bei einem UPDAT in RPG musst du ja auch vorher per CHAIN/READ eine Satzsperre setzen und per Bezugszahl (ILE = %error) abfragen, warum nich also auch bei SQL ?
Bei SQL-Update/Delete wird noch in der Variablen SQLER3 die Anzahl betroffener Sätze gemeldet.
Ist diese = *zero, war ggf. der SQL zwar OK (SQLCOD = *zero), aber die Where-Klausel hat keinen Satz gefunden.
@Journalisierung: auch wieder so ein Mythos, habe ich bei keiner einzigen Kiste seit RISC Zeiten verifizieren können, nicht einmal bei meiner 150 oder 170 und auf keiner einzigen Kundenmaschine je ein Problem damit gefunden. Meine Erfahrung ist, dass man den Vorschlag Journalisierung mit entsprechendem Nachdruck versehen, meist durchbekommt.
@lesen/schreiben: ohne Commit Steuerung (und damit Journalisierung) gibt es den Mechanismus mit sicherem lesen/schreiben nur bei positioned updates - lesen mit Cursor und dann update .... where current of ... Ansonsten muss man mit Sperrfreien Verfahren operieren (Versionsnummer mit in die where clause aufnehmen, o.ä.)
Ansonsten ist die Konsequenz tatsächlich: keine Schreiboperationen mit SQL!!!
PS: da droht nicht nur das Handbuch, sondern auch Haftung (von wegen Stand der Technik und so...)
D*B
Bitte nicht erschlagen ...
Soweit ich weis geht commit/rollback nur bei Journalisierung.
Wustest du nicht, das das die Maschine sooooooooooo langsam macht ? :rolleyes:
(Jedenfals bei meinen Kunden )
ok, kein Sql mehr
Danke
Robi
@Fuerchau,
Na das ist ja schon was.
Mein Problem ist halt, das ich in 7-8 Mio Datensätzen bestimmte Sätze kennzeichnen muß.
Irgend ein Satz war gesperrt und ab da wurde kein Satz mehr gekennzeichnet.
So hilft mit die Anzahl Sätze, die er gemacht hat, auch nicht.
(es sei denn ich zähl vorher, alles eine Frage der Zeit !)
Ist die Reihenfolge in der ein Update durchgeführt wird immer die des PF ? Oder ggf. die keyfolge des PF?
@Dieter
wenn dieser Job dann, z.B. weil der letzte Satz gesperrt war
alle updates zurück dreht ist mir auch nicht geholfen.
Robi
Nun ja, das mit der nachträglichen Journalisierung in Alt-Anwendungen stellt sich m.U. nicht ganz so einfach dar.
Je nach ERP-Anwendung laufen mir die Platten innherhalb kürzester Zeit ziemlich voll.
Bei einer mir bekannten ERP-Anwendung werden z.B. Satzsperren über Flag-Felder (User/Jobname) geführt und damit wird sehr extensiv umgegangen.
Ein Programm macht da innerhalb kürzester Zeit mehrere 1000 Updates, die natürlich journalisiert werden.
Ausserdem hilft Journalisierung dann nicht wirklich, wenn man nicht alle betroffenen Programme unter Commit-Steuerung stellt und in ihrer Logik an dieses Verhalten anpasst.
Aber wer hat da schon Zeit für.
Für neue Programme arbeite ich inzwischen gerne mit SQL, ins besonders aus Performancegründen, da mir SQL bei komplizierteren Abfragen doch erheblich schnellere Ergebnisse liefert.
Die Programme (auch wenn ich dann erschlagen werde ;-)) bestehen aus einem Mix von SQL und RLA.
Der Update wird wie auch der Select über die Where-Klausel zugriffsoptimiert.
Wenn du natürlich einen Update für mehrere Sätze durchführst, bricht der SQL bei der ersten Sperre ab.
Hier hilft ggf. tatsächlich ein vorheriger "select ... for update of" mit anschließendem "update ... where current of".
Das mag zwar etwas langsamer sein, aber wenn du beim FETCH die Satzsperre ggf. nicht erhalten kannst (SQLCODE < 0), kannst du mit einem FETCH RELATIVE den Satz überspringen und ggf. später wieder bearbeiten.
Das mit den 'Soft' sperren kenn ich auch so.
Update dann über schreib/lese Pgm, nur Felder die sich tatsächlich geändert haben. Kleiner Pgm-Generator der alle automatisiert (und ein wenig verlangsamt) und solche Porbleme treten nicht auf.
Ist hier aber nunmal anders.
Wenn ich das Pgm umstelle und selber 'Fetche' ist mir das vorgehen klar. Nur, von der lesbarkeit für andere, ist dan ein
Read / Update mit RPG besser.
Um den Sourccode klein zu halten (und für alle lesbar) habe ich halt o.a. Stmt verwendet.
Danke an alle
Robi
... das kann man so nicht stehen lassen: Was das 'volllaufen' der Platten angeht, man kann die Größe der Receiver begrenzen und automatisch löschen lassen (wenn man wil, vorher auf Band ziehen lassen). Journalisierung erfordert keine Commit Steuerung (das gilt nur umgekehrt) und hat auch schon Wert an sich, man hat im Fehlerfall einfach mehr Informationen und zusätzlich kann man in "kritischen" Programmen Commit einsetzen und für Schreibzugriffe die Satzsperrmechanismen steuern - alles Maßnahmen, die mehr Zeit einsparen als kosten.
Bei der Kennzeichnung kann man natürlich das Kennzeichen mit in die Where clause nehmen und dann probieren, bis alle gekennzeichnet sind, aber Eleganz ist was anderes...
D*B
Nun ja, das mit der nachträglichen Journalisierung in Alt-Anwendungen stellt sich m.U. nicht ganz so einfach dar.
Je nach ERP-Anwendung laufen mir die Platten innherhalb kürzester Zeit ziemlich voll.
Bei einer mir bekannten ERP-Anwendung werden z.B. Satzsperren über Flag-Felder (User/Jobname) geführt und damit wird sehr extensiv umgegangen.
Ein Programm macht da innerhalb kürzester Zeit mehrere 1000 Updates, die natürlich journalisiert werden.
Ausserdem hilft Journalisierung dann nicht wirklich, wenn man nicht alle betroffenen Programme unter Commit-Steuerung stellt und in ihrer Logik an dieses Verhalten anpasst.
Aber wer hat da schon Zeit für.
Für neue Programme arbeite ich inzwischen gerne mit SQL, ins besonders aus Performancegründen, da mir SQL bei komplizierteren Abfragen doch erheblich schnellere Ergebnisse liefert.
Die Programme (auch wenn ich dann erschlagen werde ;-)) bestehen aus einem Mix von SQL und RLA.