View Full Version : Commit ausschalten, Fehler
Hallo
Wir arbeiten OHNE Commitment!
Wir haben eine mit SQL erzeugte Datei die wir per RPGLE Pgm füllen.
In diesem Pgm lesen wir mit SQL (fetch) eine andere Datei, verschieben Werte und schreiben per write in die SQL Datei.
Als letztes kommt ein
C/exec sql
C+ insert into lib/datei select f1, f2, F3, f4, 0 from dateix where bed_1 = 'X'
C/end-exec
Das ist zur Laufzeit nicht gemacht worden, der Fehler deuete auf fehlendes Commit.
Wenn ich in dem Pgm unmittelbar VOR dem .... insert Block ein
C/exec sql set option commit=*none
C/end-exec
einbaue kann ich nicht mehr wandeln
MSG ID WTK SATZ TEXT
SQL5066 0 62 Vorkompilierungsauswahl COMMIT mit Anweisung SET OPTION
geändert
SQL0084 30 62 Position 17 SQL-Anweisung nicht zulässig.
C/EXEC SQL SET OPTION COMMIT=*NONE
C/END-EXEC
DAs SET steht an position 17!
Kann da bitte jemand helfen?
Danke
Andreas_Prouza
26-04-21, 11:19
Die SET OPTION Anweisung muss im Source das erste SQL Statement sein.
Schiebe es einfach nach oben, dann sollte es passen.
lg Andreas
Hat geklappt, Vielen Dank!
Dietlinde Beck
Wir arbeiten OHNE Commitment!
Das ist der Fehler! Wer hat euch denn so einen Unfug eingeredet?
D*B
holgerscherer
26-04-21, 14:19
Das ist der Fehler! Wer hat euch denn so einen Unfug eingeredet?
Vielleicht ein Performance-Berater? Man hört ja so einiges den lieben langen Tag...
... auch das ist Unfug. Commit fördert asynchrones schreiben, was ein positiver Faktor ist. Davon abgesehen wird Leistung an anderen Stellen verbrannt und am teuersten sind Fehler, die in die Datenbank eingebrannt werden.
D*B
Also Journalisierung und Commit-Steuerung war noch nie ein Performanceproblem.
Eher sind viele Indizes beim Insert ein Problem, wobei hier zwischen Unique-/Nicht-Unique noch unterschieden wird.
Unique-Indizes werden sofort geprüft und gepflegt, Nicht-Unique-Indizes werden verzögert gewartet.
Deshalb sollte man nicht so viele Unique-Indizes verwenden.
Allerdings habe ich auch bei 30 - 50 Indizes bei der AS/400 noch nie Probleme bekommen.
Da hat der SQL-Server schon eher dran zu knacken.
Also Journalisierung und Commit-Steuerung war noch nie ein Performanceproblem.
... bei Georgs Elektroheizung vielleicht, bei der /38 sicher. Das ist aber schon 38 Jahre her und hängt der AS/400 heute noch an - kein Wunder, dass das System als altmodisch verschrien ist, obwohl es die Anwender und Protagonisten sind und die Büchse nix dafür kann. Manch eine*r meint, wenn man den neuesten Namen für die AS/400 kennt und verwendet, sei man auf dem Stand der Technik.
D*B
holgerscherer
26-04-21, 20:13
Manch eine*r meint, wenn man den neuesten Namen für die AS/400 kennt und verwendet, sei man auf dem Stand der Technik.
D*B
Heute gehört: "Wir aktualiseren unser IBM i bald, sind noch auf V6R1"
*keuch*
Ich erlebe das häufiger, daß wichtige Funktionen deaktiviert werden wg angeblicher Performance-Sorgen. Und später erinnert sich keiner und es heißt, "das Ding kann das nicht".
Schaut Euch nur immer die Fragen an: "Wie kann ich ohne Audit-Journal herausfinden, wer XYZ gemacht hat?"...
-h
Also für das Audit-Journal muss auf jeden Fall der Betriebsrat herangezogen sowie die Vereinbarkeit zum DSGVO geprüft werden. Immerhin werden hier massiv personenbezogene Daten gesammelt.
Das ist zwar nicht schlimm, allerdings darf dies nicht personenbezogen ausgewertet werden.
Hier gilt das Prinzip: Man muss den Täter auf frischer Tat erwischen, eine Überwachung darf nur von der Staatsanwaltschaft bei begründetem Verdacht angeordnet werden.
Außerdem ist die Erhebung der Daten auf genuau die verdächtigte Person einzuschränken.
Die Fragestellung "Wer hat XYZ gemacht" darf so gar nicht erst gestellt werden, da generell die Unschuldsvermutung gilt.