AW: [Allegro] Allegro: diverse Probleme

[Bernhard Eversberg]

Thomas Fischer schrieb:

>>Nein, das geht uns genauso. Irgendwas ist immer.
> 
> Beruhigend(?).
Nein, es ist nur die allgemeine Erfahrung mit Software aller Art.
> 
> 
>>>Ich bin gerade dabei, eine neue Datenbank aufzubauen und habe 
>>
>>bis jetzt die folgenden Problem gehabt (V. 26.1):
>>
>>>- 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.

> 
> 
> Das verstehe ich nicht. Mein Importaufruf sieht so aus: 
> 
> %-p%\import -f5 -s0 -kgebd -e IMPORT2/%-D%\Test.glg -m0 -v0 -i IMPORT1 -d%IMPORT% 
> 
> das heißt, ich gebe mit dem Parameter -d die Datei an, die meine neuen Daten enthält. Ich weiß nicht mehr, wo ich das her habe, es funktioniert aber (na ja, so weit man hier von funktionieren sprechen kann - jedenfalls wird diese Datei dann mit der Importparameterdatei IMPORT1 verarbeitet).
> Dann ist für das Datenverzeichnis aber kein Platz da, es steht vor dem Aufruf allerdings in der Variablen %-D%.
> 
Mit -d wird bei IMPORT das Verzeichnis angegeben, wo die Fremddaten
liegen. Wenn dies zugleich das Datnbankverzeichnis ist, wo die 
Zieldatenbank liegt, ist es ok, sonst hat man keine Möglichkeit,
es anzugeben. %-D% nützt nichts.

> 
> Kann ich beizeiten schicken, mit dem entsprechenden Datensatz. Letztere sind allerdings nicht öffentlich (gehören mir nicht).
Wir geben nichts davon weiter.
> 
> 
> Heißt das, dass ich mir meine Datenbank mit index füllen sollte? Aber wie bekomme ich dann die Identnummern?
 > Und den Datumsstempel für die Aufnahme?
Die kriegt man in der Tat nur mit UPDATE.

> Oder einen Update mit deaktivierten Indexeinträgen, und dann neu indexieren?
Das ginge.

> 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
> 
> 
> 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.

> und das stört erheblich.
> 
> 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?

B.E.