[Allegro] srch32 und aufgebohrte Datenbanken
Thomas Berger
ThB at Gymel.com
Do Nov 10 15:01:25 CET 2011
Lieber Herr Eversberg,
>> Vergleich der Ergebnisse von acon und srch32 zeigt, dass es Abweichungen
>> dort gibt, wo explizit nachgeladen wird:
>>
>> #ucc +#J0v i4,_ f"_" e"[ ∟▼/.,-;:_!%&/()¶{}=?+*~#'<>|·]" e"]" P"=" |:2
>>
> Was für Abweichungen? Natürlich haben wir auch Nachladungen getestet,
> braäcuhten also auch hier nähere Angaben oder ein Testpaket
Die fragliche Parameterdatei (ein MAB-Export) arbeitet nicht mit i4
und die zitierte Zeile ist die m.E. einzige relevante Nachladung
bei dem Lauf (und ich wollte zeigen, dass sie eher harmlos ist).
Unmittelbar nach dem Nachladen erfolgen Akzentvertauschungen, in
einem Datensatz erfolgen u.U. auch mehrere Nachladungen (allerdings
nicht rekursiv), http://bugzilla.gymel.com/show_bug.cgi?id=466
ist ja ein (leider seit 4 Jahren unbehandeltes und immer aktueller
werdendes) Beispiel fuer ein Problem, wo das Straucheln erst bei der
zweiten Nachladung innerhalb der Verarbeitung eines Ausgangssatzes
auftritt.
Die Abweichungen bestehen darin, dass im Export da, wo nachgeladene
Inhalte stehen sollten, nichts steht. Ich habe das aber etwas
zurueckhaltender formuliert, weil ich nicht kontrolliert habe, ob
*jede* Nachladung gescheitert ist.
Die Dateinummer 196 bei den zitierten Meldungen ist ebenfalls jene,
wo die nachzuladenden Saetze aller Wahrscheinlichkeit nach wohnten,
jedenfalls nicht die Nummer der Datei, die der Export in dem
Moment durchpfluegte. Die Datei 196 selbst ist trotz Aufbohrung
mit etwa 4,5MB nicht besonders gross.
Falls Sie nach den Hinweisen immer noch nichts finden, werde ich Ihnen
ein Testpaket aufkochen.
viele Gruesse
Thomas Berger
Mehr Informationen über die Mailingliste Allegro