generische Artikelsuche / subfileausgabe

[programmer]

Folgende Problemstellung:

Wir bräuchten eine generische Artikelsuche (wie Suchmaschinen im Internet)

Des User bekommt ein 20stelliges Eingabefeld für die Suche angezeigt und nach Datenfreigabe sollen die Datensätze unterhalb in einem Subfile angezeigt werden.

Mir ist klar das es mit opnqryf und rpgIII zu lösen geht, bitte aber um Hilfe, wie der Ablauf ausschauen muss.

[Fuerchau]

Am einfachsten ist es direkt mit SQL:

/exec sql
select * from artikel
where ArtBez like :Input
/end-exec



Um dies in RPGIII bzw IV zu lösen ist das schon etwas aufwändiger, da OPNQRYF immer wieder neu Durchgeführt werden muss:

1. RPG mit UserEingabe
2. CLP mit OPNQRYF und OVRDBF ... SHARE(*YES)
opnqryf ... QRYSLT(('fieldx *eq %like(' *cat UserI *cat ')')
3. RPG mit Ausgabe in Subfile und Anzeige

[Wuntvor]

Wie wäre es mit dem SCAN Befehl direkt in RPG???

[Fuerchau]

Nun ja, der SCAN geht zwar auch, bedeutet aber, dass ich immer ALLE Daten bearbeiten muss.

SQL löst das etwas effizienter.

[BenderD]

Hallo

@Wuntvor klare Frage, klare Antwort: schlecht, oder willst Du da einen full Tablescan im Programm machen und dann unsortiert rauswerfen???

Da ist embedded SQL deutlich im Vorteil, da kann man die ganzen Suchkriterien dynamisieren und eine Auswahlmaske vorschalten, oder, oder oder... Wer mal einen SQL Kurs bei mir gemacht hat, kennt das aus den Übungen.

mfg

Dieter Bender

[Wuntvor]

Ja will ich und habe ich auch schon mit erheblichen Datenmengen gemacht.
die Frage der Sortierung ist ja eine Frage des vorigen Dateizugriffes. Wenn ich die Frage korrekt verstanden habe, will programmer einen Teilstring innerhalb der Artikelbezeichnung oder Beizeichnungen suchen und je nach Treffer ausgeben oder nicht. Somit ist diese Suche eine Selektion.
Sortierung ergibt sich aus Lesereihenfolge also LF.

Wir streiten uns aber nicht, daß es in SQL besser und vor allem schneller gehen kann.

[tfroehlich]

Hallo,

eine solche Funktionalität wäre auch durch den
qclscan gegeben im RPG-Programm.
Die logische Datei müsste natürlich nach dem Suchfeld
angelegt sein. Die Performance könnte natürlich auch darunter
leiden, da der Befehl jeden Datensatz prüft.

Möglich ist dies ja auch auf älteren Maschinen/Versionen.
Ich habe derzeit noch zwei CIsc-Maschinen am Bein.
SQL-Fehlanzeige!

Gruss Thomas

[Fuerchau]

Die LF nach dem Suchfeld anzulegen macht ja überhauptkeinen Sinn, da das Finden nun mal sehr variabel ist.

Auch auf V3R2 gab's schon SQL und gehört auch zur Laufzeit-Umgebung.
Wenn du also auf einer Maschine mit V4 SQL-Programme entwickelst und für V3R2 generierst, werden die meisten auch laufen.

[AndreasH]

um noch einen auf die SQL Variante draufzusetzen:
Wenn deine Anwender Groß/Kleinschreibung nicht berücksichtigen wollen das Bildschirmfeld ohne CHECK(LC) definieren.
Wenn Du es in einem Programm machen möchtest mit prepare Klausel arbeiten.
Beispiel: Dein Eingabefeld ist in Format01 und heißt INPUT

D LikeFeld        S                   like(INPUT)
D SQLSTMT         S            512 
D SATZ_DS       E DS                  EXTNAME(Artikel)
 /free
   DOW *INKC = *OFF;
   ExFmt Format01;
   if *INKC;
    leave;
   endif;
   LikeFeld = '%' + Input + '%';
   SqlStmt = 'select * from Artikel where upper(ArtBez) like ' +
   X'7D' + LikeFeld + X'7D';
 /end-Free
 * Prepare SQL Statement
C/exec sql PREPARE S1 FROM :SQLSTMT 
C/end-exec
 * Declare Cursor           
C/EXEC SQL declare c1 cursor for s1 
C/END-EXEC                  
 * Open Cursor  
C/EXEC SQL OPEN C1      
C/END-EXEC 
 /free     
  dow SQLCOD <> 0;
 /end-Free
 * Fetch a row                       
C/EXEC SQL FETCH NEXT FROM C1 INTO :Satz _DS
C/END-EXEC                              
 /free
   if SQLCOD <> 0;
     Leave;
   endIF;
   exsr WriteSflRec;
  endDO; // while SQLCOD <> 0;
 /end-Free
 * Close the cursor 
C/EXEC SQL close c1         
C/END-EXEC 
 /free
   endDO // while *INKC  = *off;
   *inlr = *on;
 /end-Free

Ich denke, mit diesem Gerüst sollte der rest nicht schwierig sein

Gruß

[BenderD]

Hallo,

nochmal mit dem record level access und dem SQL, es geht hierbei nicht um Performance, sondern um Funktionalität.
Bei record level access habe ich das Problem, dass ich je nach Art einer Vorauswahl verschiedene Zugriffspfade brauche und wenn man ein Programm anpackt, dann eben richtig.
Ich würde die flexiblere Variante immer auch dann bevorzugen, wenn sie 30% langsamer ist als die andere, wenn die Gesamtverarbeitungszeit okay ist, für so eine Vorauswahl ist eine Sekunde durchaus angemessen.

Dieter Bender

[B.Hauser]

Hallo Andreas,

3 kleine Anmerkungen:

1. x'7D' für Hochkomma sollte vermieden werden, da dieser Hex-Code nicht international ist.
Statt x'7D' ein zwei Hochkomma benutzen.
Am besten man verwendet dafür eine Konstante.

2. Es sollte nicht auf SQLCOD = 0 sondern auf SQLCOD = 100 oder besser auf SQLSTT = '02000' abgefragt werden.
Zwischen Release V4R5M0 und Release V5R1M0 wurden einige Warnungen (SQLCOD 1-99) eingefügt.
Bei diesen Warnungen wird der Satz korrekt verarbeitet.
In Deinem Beispiel würde sogar die Schleife verlassen werden.

2. Sortierung und Auswahl unabhängig von Gross- und Klein-Schreibung steuert man eleganger über die Sort-Sequence:
C/Exec SQL
C+ Set Option SrtSeq = *LangIdShr
C/End-Exec

Bei dieser Variante ist die Verwendung der Skalaren Funktion UPPER nicht notwendig.

Überigens die Sortier-Reihenfolge kann man auch bei logischen Dateien angeben.

Birgitta

[AndreasH]

Hallo Britta,
danke für die Ergänzungen.
@Es sollte nicht auf SQLCOD = 0 ... abgefragt werden:
Ich werde meine "Schablone" nun auf SQLCOD >= 0 und <= 100 ändern.
Fix auf DOU SQLCOD = 0100 oder SQLSTT = '02000' als Schleifenbdingung würde die Gefahr einer Endlosschleife beinhalten, sollte ein anderer Programierer mal das Prepare statement ändern und der prepare nicht ausgeführt werden können wegen falschen Spaltennamen oder schlicht falschem Syntax.

@Sortierung und Auswahl unabhängig von Gross- und Klein-Schreibung steuert man eleganter über die Sort-Sequence:

C/Exec SQL
C+ Set Option SrtSeq = *LangIdShr
C/End-Exec

Dabei wird Groß- Kleinschreibung zwar für die Sortierung benutzt, aber nicht für die Selektion.
SELECT * FROM DATEI WHERE Feld like '%eV%'
findet Satz Feld = "Germania eV" aber nicht Satz Feld = "German DEVELOPMENT".
Mein Ansatz war dahingehend, beide zu finden.

@1. x'7D' für Hochkomma sollte vermieden werden, da dieser Hex-Code nicht international ist.
Wieder was dazu gelernt. Habe bisher immer HY als Const(X'7D') definiert, Const('''') ab jetzt