Compileroption Commit

[Joe]

Hallo Forum

Nach Installation einer neuen I5 mit V5R4
wird die Compiler-Option Commit(*NONE) beim CRTSQLRPGI ignoriert. DSPPGM zeigt Commit *CHG.
Wenn ich im SQLRPGLE EXEC SQL und Option commit *none eingebe, wird dies übernommen.

Wer kennt das Problem?

Gruß Joe

[Joe]

Eigener Nachtrag:

Ich habe nach der Installation einen CHGCMDDFT Commit(*NONE) für CRTSQLRPGI eingebenen.

Dieser Parameter wird auch korrekt angezeigt.
Erst durch erneutes eingeben von *NONE (also überschreiben mit * oder *NONE) wird diese Option richtig übernommen.

Ist das ein Fehler im Command-Prompt?


Gruß Joe

[BenderD]

nicht nur das, sondern auch ein Fehler in deiner Programm Erstellung, das kann einem doch nicht wirklich egaL sein, ob man falsche Daten in der Datenbank stehen hat?

D*B

Eigener Nachtrag:

Ich habe nach der Installation einen CHGCMDDFT Commit(*NONE) für CRTSQLRPGI eingebenen.

Dieser Parameter wird auch korrekt angezeigt.
Erst durch erneutes eingeben von *NONE (also überschreiben mit * oder *NONE) wird diese Option richtig übernommen.

Ist das ein Fehler im Command-Prompt?


Gruß Joe

[Fuerchau]

@Dieter
Was bring Commit=*chg ohne Journal ?
Nur Laufzeitfehler!

[BenderD]

was bringen updates, die Stuss in die Datenbank malen? Ohne Commit sind mit SQL selbst elementare updates Waffenschein pflichtig und zur Aktivierung von Journalisierung ist auch bei RLA zu raten - selbst wenn man kein Commit verwendet.
Die AS400 krankt nicht zuletzt an ihren Knochen konservativen Anwendern und wenn denn final die AS400 rausfliegt, bei SAP, Oracle, SQL Server und Co. da geht das dann auf einmal alles...

D*B

@Dieter
Was bring Commit=*chg ohne Journal ?
Nur Laufzeitfehler!

[Fuerchau]

Ja, ja, wenn nur bloß die blöden Altanwendungen nicht wären, die in Sekunden tausende Pseudo-Updates (Feldinhalt rein und wieder raus) in zig Dateien durchführen und somit jede Journalisierung zur Illusion werden lassen.

[Joe]

was bringen updates, die Stuss in die Datenbank malen? Ohne Commit sind mit SQL selbst elementare updates Waffenschein pflichtig und zur Aktivierung von Journalisierung ist auch bei RLA zu raten - selbst wenn man kein Commit verwendet.
Die AS400 krankt nicht zuletzt an ihren Knochen konservativen Anwendern und wenn denn final die AS400 rausfliegt, bei SAP, Oracle, SQL Server und Co. da geht das dann auf einmal alles...

D*B

Hallo.

Würde ich ja gern machen- aber mir fehlt noch der "UPDATE" für meinen konservativen Vorgesetzten der auch noch die
Entwicklung vorschreibt.

Danke für die Antwort.

Gruß Joe

[BenderD]

dann sollte man dem mal sagen, dass Journalisierung ein phantastisches Mittel ist, Fehler zu analysieren und zu bereinigen; und dass man ohne Commit Satzsperren (fast) nicht steuern kann; der letzte gelesene Satz eines Cursors bleibt gesperrt, ein select into sperrt überhaupt nicht, sprich: bei zwei konkurrierenden Updates geht einer verloren!!!

@Baldur: in solchen Schätzchen sollte man nicht mit SQL anfangen, da passt RLA besser rein

D*B

Hallo.

Würde ich ja gern machen- aber mir fehlt noch der "UPDATE" für meinen konservativen Vorgesetzten der auch noch die
Entwicklung vorschreibt.

Danke für die Antwort.

Gruß Joe

[Fuerchau]

@Dieter
Die Mischung machts.
In vielen Fällen (bei Massenupdates o.ö.) ist SQL einfach performanter.
Bei komplizierteren Suchfunktionen hat sich der Select als performanter erwiesen.
usw.usw.

Es gibt viele Gründe, neues auf alten Anwendungen nun doch mit SQL zu machen.

Um den CHAIN mit Satzsperre hinzubekommen, verwende ich gerne (auch wenn man ihn nicht gerne sieht)

declare blbla cursor for
select ....
for update of ...

In diesem Fall gibts sogar ein Lesesperre !

[BenderD]

richtig muss es sein, falsch kann noch so schnell sein, dein Beispiel mit der Lesesperre grauselig, wenn jetzt der Kundensatz angezeigt wird, bleibt er gesperrt bis der Anwender aus der Mittagspause zurück kommt...

@Dieter
Die Mischung machts.
In vielen Fällen (bei Massenupdates o.ö.) ist SQL einfach performanter.
Bei komplizierteren Suchfunktionen hat sich der Select als performanter erwiesen.
usw.usw.

Es gibt viele Gründe, neues auf alten Anwendungen nun doch mit SQL zu machen.

Um den CHAIN mit Satzsperre hinzubekommen, verwende ich gerne (auch wenn man ihn nicht gerne sieht)

declare blbla cursor for
select ....
for update of ...

In diesem Fall gibts sogar ein Lesesperre !

[Fuerchau]

@Dieter
Seit wann bist du so mies drauf ?

Natürlich ist das so, aber das ist mit RLA ja genauso bescheuert, wenn man denn so programmiert.

Genauso, wie ich mit RLA Satzsperren gezielt einsetze, genauso kann ich dies eben auch mit SQL erreichen.
Mehr wollte ich damit doch gar nicht sagen.

Grundsatzdiskussionen über Altanwendungen erübrigen sich ja sowieso.
Und neue Funktionen in alten Anwendungen müssen nun mal häufig auch nach den alten Prinzipien eingebracht werden.

[BenderD]

genau hier sind gravierende Unterschiede zwischen RLA und SQL:
- RLA steuert Satzsperren über Open Bestimmung
- RLA Sperr Freigabe durch write oder unlock
- SQL steuert Satzsperren über Commit Controll
- SQL gibt frei mit Commit/Rollback

D*B

Natürlich ist das so, aber das ist mit RLA ja genauso bescheuert, wenn man denn so programmiert.

Genauso, wie ich mit RLA Satzsperren gezielt einsetze, genauso kann ich dies eben auch mit SQL erreichen.
Mehr wollte ich damit doch gar nicht sagen.