RPG Free mit SQL / Joins / mit QSYS2.USER_INFO

[Fuerchau]

Man kann alles auch übertreiben.
In 99,99% aller Fälle reicht die Fehlerbehandlung mit SQLCODE vollkommen aus.
Schließlich testet man ja auch seine Programme bevor sie in den Echteinsatz gehen.
Und den Fehlertext benötige ich i.d.R. zur Laufzeit überhaupt nicht.

Mit meinem Verfahren arbeite ich seit über 20 Jahren absolut problemlos;-).

Warnungen sind i.d.R. auch nicht einfach zu ignorieren. In der Doku steht auch nur irgendwas von > 0 und <> 100. Da ist es sicherer dann lieber nicht weiter zu arbeiten als sich in die sehr detailliertere SQLSTATE-Auswertung zu stürzen die man ja vorher programmieren muss.

Fehler wie fehlenden Null-Anzeiger treten ja nur zur Entwicklungszeit auf.
Wer die Datenbankstruktur nach der Fertigstellung so anpasst, dass Programme nicht mehr laufen, gehört sowieso verhaftet.

[BenderD]

Das musst Du mir mal zeigen wo der Fehlertext in der SQLCA stehen soll.
Ich habe bislang noch keinen gefunden. In SQLERM stehen zwar die Variablen Message-Texte aber ohne die eigentliche Message, die man sich mühsam aus der Mesage-File QSQLMSG und dem SQL Code ermitteln muss bringt das nichts.
GET DIAGNOSTICS bringt den kompletten Message-Text incl. der eingesetzten variablen Message-Texte.
Mit Deiner Lösung hebelst Du das komplette Fehlerhandling!

Außerdem sollte man niemals im DOW oder DOU den SQLCode abfragen und schon gar nicht auf 0.
Weitere SQL-Statements könnten innerhalb der Verarbeitungsschleife ausgeführt werden, die ihrerseits den SQLCODE (und SQLSTATUS) setzten. Eine dieser SQL Abfragen könnte z.B. den SQLCODE 100 zurückbringen und dann schaut man bedeppert, weil die Verarbeitung mittendrin beendet ist.

Auch sollte man nie den SQLCODE nie direkt auf 0 abfragen sondern immer auf 100 oder < 0. Es gibt situationen in denen eine Warnung ausgegeben wird, die aber für die Verarbeitung als solche uninteressant ist. Bei einer Warnung wird ein positiver SQLCODE (<> 100) ausgegeben. Eine solche Warnung würde dann auch wieder bewirken, dass nur die Hälfte abgearbeitet wird.

Sofern man lieber den SQLSTATE prüft, sollte man die ersten beiden Ziffern (Status Gruppe) vorrangig prüfen:
00 = Alles Okay
01 = Warnung
02 = nicht gefunden
Alles andere ist Fehler

Man kann sich natürlich eine generische Fehlerbehandlung bauen, die nach jedem SQL-Statement aufgerufen wird. Dadurch spart man sich eine Menge Kopiererei und ggf. auch eine Menge Wartungsaufwand.

Birgitta

... was soll denn diese Klugscheißerei? Foren leben davon, dass nette Menschen wie Baldur Arbeitshinweise geben, mit denen Fragende weiter arbeiten können. Produktionsreifer Code erfordert selbstredend ein wenig mehr Aufwand. Wenn Du Baldur schlicht nicht leiden kannst, setz ihn auf die Ignore Liste oder schick ihm eine grobe PM oder beiß in die Schreibtischkante, je nach Präferenz.

D*B

[malzusrex]

Ich hoffe DCDEAL wird nicht gleich verschreckt...

ist doch öffters so. 3 Programmierer --> 5 Lösungen

Bitte die Kanonen wieder einfahren

Gruß
Ronald

[dcdeal]

Alles kein Problem!!! Grüsse an Fr. Hauser, ich war vor kurzem noch bei der POW3R, super SQL Vortrag.
Grüsse an alle.