View Full Version : generische Artikelsuche / subfileausgabe
programmer
19-02-04, 10:59
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.
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
Wie wäre es mit dem SCAN Befehl direkt in RPG???
Nun ja, der SCAN geht zwar auch, bedeutet aber, dass ich immer ALLE Daten bearbeiten muss.
SQL löst das etwas effizienter.
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
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
19-02-04, 12:49
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
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.
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ß
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