[Allegro] Getrennte Listefür Entwickler sinnvoll?

[Arno Mentzel-Reuters]

Liebe Liste,
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.
--
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.
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).
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.
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).
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.
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.
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?
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!
---
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 (*Server-Neustart 
erforderlich*). 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.

Das war jetzt viel zu lesen, ich höre besser auf.
Viele Grüße
Arno Mentzel-Reuters


-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20120305/4fe0d3cc/attachment.html>