AW: AW: [Allegro] Allegro: diverse Probleme

[Thomas Fischer]

Hallo Herr Eversberg,

> >>>- Ich habe versucht, in der *.cfg die Angabe für Teilfeldzeichen
> >>>  mit AltGr-2 einzugeben. Das geht so nicht, jedenfalls mit einem
> >>>  normalen Editor: Allegro stürzt ab. (Das Zeichen, das so entsteht,
> >>>  ist ASCII 178.) Ich habe mit einem Hexeditor ein ASCII 31 
> Also mit Code 178 an der Stelle stürzt es ab, oder wie ist das gemeint?
> Was stürzt ab und wie sieht das aus?
> 
> > 
> > Kann man denn tatsächlich irgendwo AltGr-2 nehmen? Und das 
> sollte einerseits entsprechend in der Dokumentation stehen und 
> andererseits sollte A99 nicht abstürzen .
> AltGr-2 ist der Code 178, nichts anderes. Per o.apt wird er intern
> in 31 verwandelt.

Daran könnte es liegen.
Ich habe mein o.gpt deaktiviert, da ich befürchte, es würde mit meinen UTF-8-Daten nur Unsinn anstellen.
Andererseits stürzen auch meine anderen Datenbanken ab, wenn ich in die Konfiguration

t2
k4
²37
cg00  		#00 enthält die Identnummer
ci:?6  		IDN 6 stellig im Register 10 indexieren
cn99n  		Datum der Neuerfassung
ce99e  		Datum der Berabeitung

schreibe.


> > Das beantwortet allerdings die Frage nicht, wie mit einer 
> unsichtbaren Grenze umzugehen ist.
> INDEX gibt am Ende den Hinweis, welcher Datensatz die meisten
> Indexeintraege erzeugte, und wieviele das waren. Sind es mehr als 500,
> weiß man, daß es mit PRESTO und a99 nicht recht gehen wird. Wobei wir
> a99 an der Stelle noch aufbohren könnten.
> 
> > Und: es geht mir ja  nicht um Volltexte, sondern um 
> bibliographische Daten, die eine Beschreibung enthalten, in der 
> ich suchen will. 
> Solche Beschreibungen grenzen ja an Volltexte

Woran es grenzt ist mir egal, so sind halt die Daten. Wenn Allegro das nicht kann, heißt das wohl, dass bibliographische Referenzwerke mit Abstracts mit Allegro nicht effektiv verwaltet werden können. Ich habe mit diesem Problem schon bei meiner MathDiss-Datenbank gekämpft: Dissertationen mit Abstract konnte ich da nur mir Gewalt unterbringen, durch eher willkürliche Aufteilung der Abstracts auf mehrere Felder.

> > Derzeit habe ich neue Probleme:
> > Plötzlich steht beim update ein Teil der Abfrageliste vor dem 
> Datensatz, in der Logdatei steht dann:
> >  
> > ···
ource"ÿ27 "Reference (ci)"ÿ29 "Type (dt)"ÿ41 "MSC (cc)"ÿ50 
> "Year (py)"ÿ95 "Owner"ÿ%·0 0596.05004·10 Historical perspective 
> of finite mathematics·  ... usw.
> > 
> Wie sehen die m-Werte in der CFG aus? Die Datei müßten wir mal sehen und
> einige Daten.

Dies Phänomen ist glücklicherweise nach einem gewaltsamen Abbruch nicht wieder aufgetreten, so dass ich nicht mehr sagen kann, ob es mit bestimmten Daten zusammenhängt.
Die m-Werte sehen so aus (Kopie aus *.cfg):
mr10000      maximal ErgebnismengengrӇe  (bis 16.000)
mr15000    aktivieren, wenn man gengend Speicher hat
            (Reduktion auf 1000 bringt 60K !)
mk2500          Arbeitssp. Anzahl Kategorien (Standard 2500)
md800       Anzahl Kategorie-Deskriptoren (Standard 800)
mb200      Hintergr.Sp. Anzahl Kategorien
mB12000     GrӇe (in Byte, 5000 reicht meist)
mP10000     Phrasenspeichergr”áe (auch f?r Zwischenteile n”tig!)
mX40000    Export-Parameterspeicher


> > Und das aktuellste:
> > Mein Update hat plötzlich aufgehört, Kennnummern zu vergeben, 
> wie sie mit
> > cg00  		#00 enthält die Identnummer
> > ci:?8  		IDN 8 stellig im Register 10 indexieren
> > eigentlich erzeugt werden sollten.
> > 
> > 
> Und was steht zu dem Zeitpunkt im Reg. 10, dort wo die Nummern landen 
> müßten?

Dort stand wahrscheinlich 00000012.
Warum dann bei Nr. 00003245 wieder zu zählen begonnen wurde ist mir rätselhaft.

Mit freundlichen Grüßen
Thomas Fischer