Re: AW: [Allegro] Gibt es eigentlich noch CockPit-Anhänger???

[Mentzel-Reuters]

Lieber Herr Eversberg,
 insgesamt kommen meine Anregungen teilweise aus einem "abwegigen 
Bereich", denn wer macht schon Volltext-Datenbanken mit Allegro? Aber es 
geht (wie man sieht). Manches davon habe ich dannn, einmal hellhörig 
geworden, auch am OPAC beobachtet. Ich habe mir allerdings immer 
irgendwie helfen können und mich auch nur gemeldet, weil Sie nach 
Erweiterungen der DOS-Programme fragten.

> Und wie groß soll's dann sein? Wie lang wäre Ihr längster 
> Kategorieinhalt? Beliebig geht nicht. Eine maxim. Größe von 32000 wäre 
> im a99 denkbar, aber SRCH, INDEX und UPDATE müssen ja auch noch 
> klarkommen! Nur die andernorts schon mal geforderte Umwandlung der 
> DOS-Programme in 32bit-Programme könnte abhelfen. Dafür können wir 
> keinen Termin nennen.
>
Das ist natürlich nur bei Volltexten ein Problem. Die derzeitige 
Begrenzung läßt nicht zu, daß größere Satzgefüge ganz in eine Kategorie 
geschrieben werden.  Der Punkt wäre aber als Trennzeichen eine gute und 
strukturell nachvollziehbare Größe. Ansonsten könnte man sich an bei der 
derzeitigen Digitalisierungspraxis (suche im Volltext, zeige Image) auch 
mit einer Seitenorientierung anfreunden, also etwa 2500 Zeichen (wieviel 
Arbeitsspeicher das wäre, weiß ich jetzt nicht). Dann gibt es natürlich 
auch noch die Obergrenze für den gesamten Datensatz. Als Volltextler 
würde man hier gerne ein ganzes Kapitel einspielen. Das ist eine 
dehnbare Größe, ich weiß ...  Jede Erweiterung wäre willkommen - sagen 
wir es so.

>> oder eine direkte Erkennung von Zahlzeichen (irgendwie so etwas wie 
>> "beginne bei der ersten beliebigen Zahl" oder "beginne bei einem 
>> zeichen, das nicht Zahl ist"... )
>
> Das waere wohl nicht so schwer. Der einzige Grund, warum es das noch 
> nicht gibt, ist der, daß noch nie danach gefragt wurde und auch bei 
> uns die Notwendigkeit nie aufkam.

Die Notwendigkeit entsteht, wenn man unstrukturierte Volltexte in 
Kategorien umsetzen will; ich hätte es schon häufiger gebrauchen können. 
Das ist also auch dann interessant, wenn man aus einer komplxeren 
Literaturliste Titelaufnahmen (halb-)automatisch übernehmen will, z.B. 
um sich am Erscheinungsjahr oder den Seitenzahlen zu orientieren und von 
dort aus Ort oder Verlag zu erkennen.

>
>> Problematisch ist auch, daß srch bei Export ab einer gewissen Länge 
>> von mit #t{ ...} oder p"..." eingefügtem Text das Zeichen 0 
>> reinschreibt,
>
> Dürfte nur passieren, wenn nicht  zl=0  ist

Leider nicht bei erheblicher Länge der Einfügung! Ich habe mir damit 
beholfen, die wichtigsten HTML-Elemente über die Zwischenteile in der 
*.apt zu regeln, dann kommt diese gewaltsame Unterbrechung nicht. Z.B.:
90=034 084 065 082 071 069 084 061 034 095 066 076 065 078 075
                            =  "   _        "  TARGET="_Blank
Ein Datenbeispiel kann ich jetzt nicht bieten, da ich alle Fälle auf 
diese (oder ähnliche) Weise umgangen habe:

#t89                    </PREF>
#t70                    war: CC, wird in p-html.apt zu <hr> (horizontale 
Linie)
#t60                    <table width=100%>
#t54                    <td>

Wenn ich diese HTML-Kette hintereinander ausgeben lasse, kommen mir 
undefinierte Zeichen dazwischen. Mit dem Kategorienende 0 hat ds nichts 
zu tun. Es ist jedenfalls von der Länge der Einfügung abhängig. zl=0 ist 
gesetzt.

>
> > Und die bool'schen Operatoren bei srch sind bei
>
>> einer längeren Kette von Bedingungen auch nicht mehr astrein ...
>
> Hätten Sie dafür Beispiele?
>
Auch nicht zur Hand. Ich habe mir nur schon angewöhnt, komplexere 
Anfragen in mehreren Exporten zu machen, weil für mich nicht transparent 
ist, wie sich srch verhält, wenn man mehrere Bedingungen 
aneinanderreiht. (Irgendwas wie suche a und b aber nicht c oder d - wie 
sind dann die Zuordnungen). Wenn ich damit noch einmal Probleme habe, 
werde ich mich melden.


Mit freundlichen Grüßen
Arno Mentzel-Reuters