RPG Free mit SQL / Joins / mit QSYS2.USER_INFO

[dcdeal]

ich haben nun schon einen test gemacht. Wenn ich die genauen Feldtypen, Bezeichner etc. übernehme geht es!
SUPERCOOL. danke, aber für ein paar gute beispiele dazu wäre ich dennoch dankbar. Ich such immer das halbe Internet durch.

Offensichtlich steht qualified doch für was anderes... ?

[Fuerchau]

Ja.
Ohne qualified steht jede Variable einer DS einzeln zur Verfügung, mit qualified muss die Variable der DS mit ihrem Strukturnamen also "myds.myvar" angesprochen werden.

Steht aber alles in den o.a. Handbüchern;-).

[dcdeal]

Hallo, hiermit poste ich nun noch mein Lösung, der code funktioniert nun so.

Im weiteren hatte ich noch das Problem mit der Fehlermeldung "Anzeigervariable erforderlich SQLSTATE 22002"

Man beachte die Lösung für diese Fehlermeldung,
die Variable "myind", die die NULL STATI Für die Felder zurückgibt
(Die sonst als ersten Datensatz angefügt werden - wie clever gelöst, IBM! [ha-ha])

Ich hoffe das der Code jedem Hilft, der später nach der Lösung für solcherlei Probleme Googelt.

Ein speziellen Dank nochmal an Fuerchau, der so nett war und mir geholfen hat .

  
**free
ctl-opt option(*nodebugio:*srcstmt:*nounref)  alwnull(*inputonly)  main(main);

dcl-proc main;
  dcl-ds sysUserTable QUALIFIED;
    USER_NAME char(10);
    INITPGM char(10);
    INITPGMLIB char(10);
  END-DS;
  dcl-s myind int(5) dim(256);

  dcl-s InsertErrSQLtext char(999);
  dcl-s insertState char(6);
  dcl-s testStr char(52);
  dcl-s statSQL int(10);
  dcl-s CNT int(10);


  exec sql DECLARE CUILoop SCROLL CURSOR FOR
        SELECT
        USER_NAME,
        INITPGM ,
        INITPGMLIB
        FROM QSYS2.USER_INFO A
      ;
  exec sql OPEN CUILoop;

  exec sql FETCH FIRST FROM CUILoop INTO :sysUserTable  :myind;

  // SQL DEBUG START
  // Falls hier kommt: Anzeigervariable erforderlich 22002 .. dann brauche ich hinter dem sql
  // noch eine weitere Variable, so
  // dcl-s myind int(5) dim(256);
  // exec sql FETCH FROM CUILoop INTO :sysUserTable :myind;
  Exec SQL GET DIAGNOSTICS Condition 1 :InsertErrSQLtext = MESSAGE_TEXT;
  Exec SQL Get Diagnostics Condition 1 :insertState = RETURNED_SQLSTATE;
  Monitor;
    statSQL = %dec(SQLSTATE:7:2);   // Vorsicht! es können codes mit buchstaben vorkommen.
  On-Error  *all ;
  Endmon;
  testStr = %SUBST(InsertErrSQLtext:1:52);
  dsply testStr;
  testStr = %SUBST(InsertErrSQLtext:53:105);
  dsply testStr;
  testStr = %trim('SQLSTATE: '+insertState);
  dsply testStr;
  // SQL DEBUG END

  dow (statSQL < 2000) or (CNT > 3);
    dsply %trim(sysUserTable.USER_NAME+'-'+sysUserTable.INITPGM+'/'+sysUserTable.INITPGMLIB);
    exec sql FETCH NEXT FROM CUILoop INTO :sysUserTable  :myind;
    Monitor;
      statSQL = %dec(SQLSTATE:7:2);   // Vorsicht! es können codes mit buchstaben vorkommen.
    On-Error  *all ;
    Endmon;
    dsply %trim('SQLSTATE '+SQLSTATE);
    CNT += 1;
  enddo;
  exec sql close CUILoop;
end-proc;

Hinweis zur Lösung:
In der Lösung hier benutze ich keinen Join mehr, es ist eine einfache User_Name Abfrage, allerdings funktioniert auch die join Abfrage aus der ursprünglichen anfrage s.o.)

[Fuerchau]

Noch ein paar Hinweise:

Diagnostics ist nicht nötig, da der Compiler eine SQLCA-Struktur generiert, die alle Informationen nach einem SQL enthält.
Hierzu gibt es i.W. die Variable

SQLCODE

Der Inhalt ist grob folgender:
0 = alles OK
100 = Keine Daten mehr beim Fetch
< 0 = meist schwere Fehler die ein Weiterarbeiten unnötig machen

Auch ein ggf. vorhandener Fehlertext steht dann in der SQLCA.
https://www.ibm.com/support/knowledg...ddescsqlca.htm

Dein Code wäre also übersichtlicher:

exec sql open ....;
dow SQLCODE = *zero;
exec sql fetch ....
if SQLCODE <> *zero;
leave;
endif;
// to was
enddo;
exec sql close ...;

[B.Hauser]

SQLCODE

Der Inhalt ist grob folgender:
0 = alles OK
100 = Keine Daten mehr beim Fetch
< 0 = meist schwere Fehler die ein Weiterarbeiten unnötig machen

Auch ein ggf. vorhandener Fehlertext steht dann in der SQLCA.
https://www.ibm.com/support/knowledg...ddescsqlca.htm

Dein Code wäre also übersichtlicher:

exec sql open ....;
dow SQLCODE = *zero;
exec sql fetch ....
if SQLCODE <> *zero;
leave;
endif;
// to was
enddo;
exec sql close ...;

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

[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.