<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> </div>
<div>Jetzt noch ein weng Aufklärungsarbeit!</div>
<div> </div>
<div>Beim gründlichen Überarbeiten des neuen srch.job blieb EIN Fehler doch noch unentdeckt:</div>
<div>Im Kopftext, der u.a. die Verwendung beschreibt, stand:</div>
<div> </div>
<div>
<div>// oder: ... -Rdateiname, mit term als 1. Zeile der Datei, die in dbDir liegt</div>
<div> </div>
<div>aber so muss es lauten:</div>
<div> </div>
<div>
<div>// oder: ... -r?dateiname, mit term als 1. Zeile der Datei, die in dbDir liegen muss</div>
<div> </div>
<div>Man wird das bei direkter Anwendung wohl kaum so machen. Nicht mit acon jedenfalls.</div>
<div>Genau so kann es aber auch das Programm srch, z.B.:</div>
<div> </div>
<div>
<div> srch -ddemo2\cat -r?shak -ee-1=shak.adt</div>
<div> </div>
<div>Und so läuft das auch in a35, wenn man da eine Volltextsuche mit der neuen Methodik durchführt.<br/>
Der a35fts.job konstruiert dabei den Startbefehl auf diese Weise und startet damit dann srch,</div>
<div>nicht acon! Denn srch.exe ist noch deutlich schneller.<br/>
Sowohl srch und acon löschen auf diese Art am Ende die Suchbegriffsdatei, hier also die im</div>
<div>DbDir liegende Datei "shak".<br/>
Bei Anwendung in a35 ist es so: Als Dateiname wird immer die in dem Moment eindeutige</div>
<div>Prozess-ID von acon genommen. Das ist die FLEX-Variable pid, stets eine Zahl. So kann es</div>
<div>nicht zu einem Konflikt kommen und man muss nicht selber aufräumen.</div>
<div>Wenn also die pid von acon in dem Moment 1345 lautet, dann startet acon den srch-Prozess so:</div>
<div> </div>
<div>
<div> srch -ddemo2/cat_*.ald -r?1345 -ee-1=1345.d<br/>
<br/>
Die Datei 1345.d enthält dann nichts als die Satznummern der Ergebnismenge! Die liest acon</div>
<div>ein, sortiert sie und exportiert sie mit den gewünschten Parametern in eine Datei xyz.htm,</div>
<div>wobei xyz die a35-Login-ID ist. 1345.d wird am Ende vom a35srch.job gelöscht.<br/>
Hört sich umständlich an, klar, aber anders kann's kaum gehen, wenn man die Ergebnismenge</div>
<div>auch noch sinnvoll sortiert haben will, denn srch kann das nicht auch noch erledigen. Es könnte</div>
<div>nur jeden gefundenen Satz sofort exportieren, weil es keine Ergebnismenge bilden und diese</div>
<div>dann sortieren und exportieren kann. Es kann nur rattenschnell suchen und jeden gefundenen</div>
<div>Satz sofort exportieren.</div>
<div> </div>
<div>Wir warten mal ab, ob es noch mehr Monita geben wird, bevor wir srch.job nochmal</div>
<div>aktualisieren.</div>
<div> </div>
<div>Das a35-Paket mit a35fts.job drin wird am Montag neu bereitgestellt. Dann wird man es</div>
<div>auch auf allegro-b mal ausprobieren können, um sich ein Bild zu machen.</div>
<div><br/>
Ein Tip noch: Bei SEHR großen Datenbanken wird man erleben, dass nach 30 Sekunden<br/>
eine Meldung kommt:<br/>
<b>Fatal error</b>: Maximum execution time of 30 seconds exceeded ...<br/>
Dem kann abgeholfen werden, indem man in ajax4.php z.B. folgenden Befehl einfügt:</div>
<div>
<div>set_time_limit(300);<br/>
Dann darf das Programm 300 Sekunden brauchen für den srch-Prozess, d.h. 5 Minuten.</div>
<div> </div>
<div>Im Test mit einer Datenbank, die aus 73 Dateien à 16 MB bestand, brauchte srch.exe,<br/>
um eine Ergebnismenge von 38 Titeln ausfindig zu machen, 52 Sekunden. Das ist dann</div>
<div>also für eine 16MB-Datei deutlich weniger als 1 Sekunde. Und das war ein nicht wirklich</div>
<div>neuer PC. Und wieviel mit acon und dem alten srch.job? Das wurde nicht getestet.</div>
<div>Auch der neue srch.job braucht aber viel länger als srch(.exe), denn beim srch.job wird</div>
<div>alles in der FLEX-Sprache abgearbeitet, und das ist eine interpretierende Skript-Sprache,</div>
<div>während srch(.exe)m ein kompiliertes C++-Programm ist - das macht viel aus in punkto</div>
<div>Performance!</div>
<div><br/>
</div>
<div>B.E.</div>
<div> </div>
</div>
<div> </div>
</div>
</div>
</div>
</div></div></body></html>