SETGT + %EQUAL

[rscheppe]

Liebe Helfer,

laut Handbuch ist das %equal nach SETGT (hier zwecks READPE) nicht vorgesehen (???).
Oder ?
Alternativ bleibt dann z.B. %found, readp, + dann Abfrage der Schlüsselfelder.
Ist aber umständlicher.
???
Vielen Dank schon jetzt!

[Fuerchau]

SETGT kan ja nicht %equal liefern.
Eigentlich auch nicht SETLL.
%found ist da meist auch nicht hilfreich.

Aber mit READPE/READE kannst du ja auf Schlüssel abfragen und dann %found auswerten.
Ich habe mir abgewöhnt, den Status nach SETLL/SETGT abzufragen.

Einfach:
setgt (k1:k2:k3) myfile;
reade (k1:k2) myfile;
if %found() = *on;
:
endif;

[rscheppe]

Ja, bei SETLL mache ich das auch schon seit einiger Zeit.

Danke!

[Pikachu]

Wenn du eine neue logische Datei mit umgedrehter Sortierfolge (Schlüsselwort DESCEND bei den Sortierfeldern angeben) anlegst, müßtest du wieder mit SETLL aufsetzen und mit READE lesen können.

[Fuerchau]

Wozu, wenn SETGT/READPE doch funktioniert ?

[B.Hauser]

Aber mit READPE/READE kannst du ja auf Schlüssel abfragen und dann %found auswerten.
Ich habe mir abgewöhnt, den Status nach SETLL/SETGT abzufragen.

Einfach:
setgt (k1:k2:k3) myfile;
reade (k1:k2) myfile;
if %found() = *on;

In dem Beispiel bezieht sich allerdings %Found nicht auf den READE, sondern auf SETGT.

Die Lesebefehle (READ, READE, READP, READPE und READC) können nur mit %EOF abgefragt werden. %Found wird von diesen Befehlen nicht gesetzt.

Der %Found in dem obigen Beispiel bezieht sich auf den Befehl, der den letzten %Found gesetzt hat, also auf den SETGT. Das Ganze wird umso gefährlicher, da noch nichteinmal eine Datei angegeben wurde.

Wenn Du bislang mit solchen Abfragen noch nie Probleme hattest, hattest Du einfach Glück.

Korrekt wäre:

 /Free
   SetGT (Key1: Key2: *HiVal) MyFile;
   ReadPE (Key1: Key2) MyFile
   If Not %EOF(MyFile);
      //Satz gefunden
   EndIf;
 /End-Free 

Hier noch ein Auszug aus der RPG Referenz:

%FOUND(Return Found Condition)
%FOUND returns ’1’ if the most recent relevant file operation found a record, a string operation found a match, or a search operation found an element. Otherwise, this function returns ’0’.

The operations that set %FOUND are:
File operations:
– “CHAIN (Random Retrieval from a File)” on page 611
– “DELETE (Delete Record)” on page 633
– “SETGT (Set Greater Than)” on page 781
– “SETLL (Set Lower Limit)” on page 785
String operations:
– “CHECK (Check Characters)” on page 614
– “CHECKR (Check Reverse)” on page 617
– “SCAN (Scan String)” on page 776
Note: Built-in function %SCAN does not change the value of %FOUND.

Search operations:
– “LOOKUP (Look Up a Table or Array Element)” on page 689

%EOF(Return End or Beginning of File Condition)
%EOF returns ’1’ if the most recent read operation or write to a subfile ended in an end of file or beginning of file condition; otherwise, it returns ’0’.
The operations that set %EOF are:
“READ (Read a Record)” on page 750
“READC (Read Next Changed Record)” on page 753
“READE (Read Equal Key)” on page 755
“READP (Read Prior Record)” on page 758
“READPE (Read Prior Equal)” on page 760
“WRITE (Create New Records)” on page 821 (subfile only).

The following operations, if successful, set %EOF(filename) off. If the operation is not successful, %EOF(filename) is not changed. %EOF with no parameter is not changed by these operations.
“CHAIN (Random Retrieval from a File)” on page 611
“OPEN (Open File for Processing)” on page 737
“SETGT (Set Greater Than)” on page 781
“SETLL (Set Lower Limit)” on page 785

Birgitta

[rscheppe]

Noch eines ist mir jetzt nicht klar (wir haben noch V5R3 im Einsatz):
ein %Found(), %Equal() etc. bezieht sich, da ohne Datei- Angabe, m.E. doch stets auf die letzte Operation, die einen solchen Wert verändern kann und damit auf die letzte betroffene File, oder? Siehe Beispiel von Herrn Fürchau + Antwort von Frau Hauser---

Ansonsten allen Dank, die Antwort von Pikachu war ja auch i.O., nur wollte ich gern auf eine weitere Datei, wenn auch LF, gern verzichten.

[B.Hauser]

Noch eines ist mir jetzt nicht klar (wir haben noch V5R3 im Einsatz):
ein %Found(), %Equal() etc. bezieht sich, da ohne Datei- Angabe, m.E. doch stets auf die letzte Operation, die einen solchen Wert verändern kann und damit auf die letzte betroffene File, oder? Siehe Beispiel von Herrn Fürchau + Antwort von Frau Hauser---

Richtig! Deshalb sollte man bei allen diesen Built-In-Funktionen immer den Datei-Namen mit angeben (sofern möglich). Wäre z.B. zwischen dem SETGT und dem READE in Baldur's Beispiel noch ein Statement z.B. mit OPCode LOOKUP oder SCAN, würde nach dem READE das Ergebnis von %Found der durch diesen OpCode gesetzte Wert sein. Wäre %Found(DateiName) angegeben, würde der Wert, der durch den SETGT (letzte Aktion auf die Datei, die den Schalter %Found gesetzt hat) verarbeitet werden.

Intern wird %Found als Feldgruppe/Array geführt. Wird eine Datei angegeben, wird das entsprechende Element rausgesucht. Wird keine Datei angegeben, wird der zuletzt gesetzte Wert ausgegeben.

Birgitta

[Pikachu]

%EQUAL läßt sich nur auf SETLL und LOOKUP anwenden, jedoch leider nicht auf SETGT.

[Fuerchau]

Man darf sich doch auch mal vertun.
Natürlich meinte ich %eof().

Da ich den Status meist direkt nach der Operation benötige trage ich auch den Dateinamen nicht ein (da SEU noch kein IntelliSense unterstützt ).

Brauche ich den Status später noch einmal, weise ich ihn einer Variablen "MyFileStat = %eof();" zu, da ich ja nicht immer sicher sein kann, ob ich nicht durch eine weitere Dateioperation diesen schon wieder verändert habe.

Übrigens verwende ich häufiger
setll (K1:K2:*hival) Myfile;
als setgt, so dass mir %equal auch nicht hilft.
Das Abfragen spare ich mir da grundsätzlich.
Wenn ich mit Mandantensoftware arbeite, ist der Status selten ausreichend, ich benötige den reade/readpe auf jeden Fall.

Um die Existenz, ohne tatsächliches Lesen zu prüfen, gehe ich in SQL den Weg:
exec sql select count(*) into : MyCount
from MyFile where ....;
if MyCount>*zero;
:
endif;

[B.Hauser]

... ich könnte jetzt sagen, das war doch schon immer so (auch unter RPGIII)!

Bei RPGIII konnten bei SETLL die Hoch- (Pos.71-72) und die Gleich-(Pos.75-76) Bezugszahl gesetzt werden.

Die Hoch-Bezugszahl ging an, wenn ein folgender Read erfolgreich wäre, was aber nicht heißt, dass es (mindestens) einen Satz mit den entsprechenden Schlüssel-Feldern gibt (was %Found()) entspricht.

Die Gleich-Bezugszahl ging an, wenn ein Chain mit dem gleichen Schlüssel erfolgreich gewesen wäre (was %EQUAL()) entspricht.

Dadurch kann es sein, dass %FOUND() angeht, während %EQUAL() *OFF zurückliefert, was von vielen auch hochkarätigen Schulungsleitern als Bug angeprangert wird. (Obwohl sich zu RPGIII nichts geändert hat.)

Bei SETGT konnte schon immer nur die Hoch-Bezugszahl gesetzt werden, d.h. diese Bezugszahl ging an wenn ein folgener READP erfolgreich wäre (was %Found() entspricht) . Da man beim SETGT eigentlich davon ausgeht, dass man zumindest im letzten Schlüssel-Feld den Maximal-Wert (*HiVal) angibt, damit sicher nach dem letzten Satz positioniert wird, macht die Abfrage nach einem genauen Treffer auch wenig Sinn!

[rscheppe]

...immer wieder interessant, das Forum.
Ich frage mich, warum man beim SETGT nicht einfachheitshalber ohne den *HIVAL im letzten Teilschlüssel auskommen sollte??
Wenn ich mit SETGT arbeite, lasse ich diesen stets weg und wenn ich dann READPE wieder mit diesem Teil-Key mache und mit %EOF abfrage (letzteres habe ich gerade von Euch gelernt - danke nochmals), habe ich doch mein Ergebnis!
Oder setzt bei mir mal wieder die Logik aus?