<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Liebe Liste,<br>
ich meinte es etwa so wie Herr Berger es umschreibt. Für eine große
Bibliothek würde ich Allegro gar nicht mehr empfehlen, sondern für
kleinere Häuser, und immerhin waren wir hier die ersten, die in
Bayern Allegro als lebendes Lokalsystem verwendet haben. <br>
--<br>
Was mir abhanden gekommen ist: Die Debatten in der Liste drehen sich
um Features, die mit dem was für mich allegro ausmacht - Import- und
Export-Sprache inkl. Index - nichts oder wenig zu tun haben. <br>
Vieles von den aktuellen Themen habe ich schon lange mehr oder
weniger gelungen an Perl oder Word ausgelagert und beschäftige mich
also nicht mit rtf-Ausgabe aus Allegro (diesen Teil machen z.B.
Word-Makros). <br>
Was ich aber immer wieder habe, sind Datenimporte aus weiß der
Teufel was für Quellen, die dann in das Format einer unserer
Datenbanken müssen: und das sind weiß Gott nicht nur Dinge nach dem
A-Schema, sondern alles mögliche bis hin zu zwei Volltextdatenbanken
(so was geht mit Allegro). Natürlich kann man die Importvorbereitung
auch mit Perl oder Python machen - ein Datenlieferanten hat mir z.B.
mit Tustep eine importfähige Vorlage gebastelt. <br>
Ich habe aber nun mal 18 Jahre mit Import und SRCH gearbeitet und
all diese anderen Sprachen kaum oder gar nicht gelernt (Latein und
Ostmitteldeutsch waren dann halt auch beruflich wichtiger); meine
Tustep-Kenntnisse habe ich weitgehend vergessen (allerdings
teilweise in Import sehr tustep-ähnlich gearbeitet). <br>
Mein Eindruck in der Liste ist, daß es um die Struktur der Daten
innerhalb der Datenbank gar nicht mehr geht, sondern um weit
hinausgreifende Aufsätze, aber oft weiß ich nicht einmal, wozu das
dienen soll. Muß ich ja auch nicht: nur wenn ich in einen Hype wie
seinerzeit mit dem neuen srch32 (das ich übrigens ohne Probleme
sofort eingesetzt habe) hineingerate, brauche ich mit einer Frage
nach den Parametrisierungen gar nicht zu kommen. Das interessiert
einfach nicht - bzw. ich muß die Lösung einkaufen. das klingt zwar
gut, ist es aber nicht, weil man fremde Parametrisierungen erst mal
nicht nachvollziehen kann. <br>
In jedem Perl- oder Javascriptforum gibt es Threats des Typus: ich
möchte das und das programmieren, habe folgende Zeilen probiert,
aber es geht nicht. Bei der Allegro-Liste bewegt sich das in
wolkigsten Höhen.<br>
Ein Beispiel: durch unsauberes Parametrisieren entstehen bei mir
immer wieder mal alg-Dateien, in denen die Zeichenfolge 00 13 10
erzeugt wurde (also ein angefangener Datensatz ohne Inhalt).
Passiert das nur mir? <br>
Denn es war niemals Thema, daß diese Datensätze beim alten update16
zur Blockade der TBL führten (acon -jupdate verdaut sie hingegen),
das alte srch16 kommt gut damit zurecht, das neue srch32 aber nicht.
Klar, solche Sätze gehören eliminiert. Keiner fragt, wie man die am
besten mit Allegro-Bordmitteln eliminiert - die einen wissen es
(nehme ich an), die andern wagen sich nicht dran? Das ist nur ein
Beispiel, damit komme ich schon zurecht, aber solche Fragen
innerhalb der Parameter lese ich ziemlich selten. Und ich frage
selber ja auch nicht mehr, ehrlich: man dringt mit solchen
Banalitäten (?) nicht durch!<br>
---<br>
Jetzt noch zu dem Index-Problem. Ich habe damals angefragt und
darauf hingewiesen, daß index32 jedes Filesystem zum Absturz bringt,
wenn man es so anwendet, wie es das Handbuch beschreibt (<b>Server-Neustart
erforderlich</b>). Das Handbuch geht nämlich von index16 aus,
index32 im Batch beschreibt es überhaupt nicht, verrät das aber auch
nicht. Das muß unbedingt geändert werden; aus orga.bat habe ich
jetzt funktionierende Zeilen übernommen, kann aber nicht behaupten,
wirklich zu verstehen, was da oberhalb der "klassischen"
Index-Zeilen gemacht wird. Diese Mail ist ganz sicher ausgeliefert
worden; warum sie nicht in das Berger-Archiv kam, vermag ich nicht
zu sagen.<br>
<br>
Das war jetzt viel zu lesen, ich höre besser auf.<br>
Viele Grüße<br>
Arno Mentzel-Reuters<br>
<br>
<br>
</body>
</html>