[Allegro] Datenbank kaputt?

Klaus Lehmann lehmann_klaus at t-online.de
Fr Nov 18 09:52:32 CET 2016


 
Guten Tag Herr Eversberg und Herr Fischer,
danke für Ihre Nachricht.
Am Freitag, 18. November 2016 um 09:01 schrieben Sie.
Ihre Nachricht finden Sie am Ende dieser eMail.

>> Gesendet: Freitag, 18. November 2016 um 08:38 Uhr
>> Von: "Fischer, Thomas" <fischer at sub.uni-goettingen.de>
>> ich kann mit meiner Datenbank jetzt wieder arbeiten, offenbar war ein Speicherbereich zu klein eingestellt, um meine umfangreichen P/Q-Tabellen aufzunehmen.
> Also Sie haben in der CFG den mX-Wert erhöht? Wir empfehlen seit langem mX64000
> und das steht auch in der ausgelieferten $a.cfg. Normalanwender haben nichts zu befürchten.

>> Der Fehlermeldung konnte ich das allerdings nicht entnehmen.
> Das ist bei Speicherbereichsüberläufen leider ein nicht immer verhütbares Übel - das Programm
> hat manchmal schlicht keine Gelegenheit mehr, sich aussagekräftig zu beschweren. Wir müßten
> mal endlich alles in Java neu programmieren.

ich halte den gedanklichen ansatz für weniger sinnvoll, da ein "interpreter"
von aussen hinzugezogen wird. alles was zusätzlich kommt, bremst.
oder?
(das ist aber eine annahme eines nicht-programmierers ;-)


>> Jetzt kämpfe ich mit der Optimierung meiner Indexeinträge. Theoretisch sollten
>> pro Datensatz 1000 Schlüssel, 32000 Byte je Satz
>> (http://www.allegro-c.de/grenzen.htm) möglich sein. Wie kann ich sehen, ob das funktioniert?
> Nur, indem Sie mal einen Testsatz machen, der diese Grenzen gerade eben noch einhält.

ja. alles maxcimal ausfüllen! mit markanten textstellen am ende und am
anfang. vielleicht so:
#20 0123456789blabla..blabla.......jetzt kommt das 16.000ste Zeichen im
Text: und zwar JETZT

wobei das letzte "T" eben zeichen nr 16.000 ist





>> Meine F7-Anzeige ist erheblich kürzer, fehlt dann etwas oder wird es nur nicht angezeigt?
> Es fehlt nix, alles wird angezeigt. Wie könnte ein Programm auch entscheiden, was es wegläßt
> oder warum sollte es in dieser Hinsicht etwas nicht anzeigen, was da ist? Oder fallen Ihnen
> in der F7-Anzeige Einträge auf, die da nicht erscheinen, aber erscheinen müßten?

naja. ich habe jetzt keine passenden nagetaiv-beispiele parat, die das
gegenteil "beweisen", aber ich erinnere mich an folgendes:

wenn mit F7 SEHR viel angezeigt werden soll, dann wechselt die anzeige
irgendwann nach einigen "seiten" das schriftbild. das scrollen wird
sehr schwer oder unmöglich.

der "rücksprung" ins fenster mit dem "i" muss nicht immer klappen. a99
zu, a99 an hilft dann.





>> Muss ich Maßnahmen ergreifen, um zu verhindern, dass ich diese Grenze überschreite?
> Mir sind keine Maßnahmen bekannt, die so etwas zuverlässig sicherstellen könnten. Es gibt,
> m.a.W., keine Einstellschrauben etwa in der Indexparameterdatei zum Begrenzen der
> Schlüsselzahl oder deren Gesamtumfang in Kilobytes. Kollege Lehmann hat ansonsten mal
> Tips gegeben für Giga-Banken.

ja, mal bitte in meine listenemails schauen, die vor 1 - 1/2 jahr
aktuell waren.

ich gehe immer so ran: entweder einen beispiel satz machen, oder sich
mit perl oder anderen werkzeugen die maximalfälle rausziehen, mit
update.job oder index.exe das ergebniss kontrollieren. und dann
rückschliessen: alles was weniger ist, funktioniert!

und auch: sich werkzeuge in skripte einbauen, die das weitere
verarbeiten stoppen, wenn etwas die grenze überschreitet.
(ähnlich dem stop/alarm-skript, was ich vor 2-3(?) monaten vorgestellt
habe, um einen "nichtstoppenden-avanti-vorgang-bei-crash" eben zur pause zu
zwingen ;-)


ich sehe grenzen in den folgenden DREI punkten:
1. datensatz nicht größer als 120.000 bytes (evtl 125.000?)

2. ein datenfeld nicht größer als 16.000 bytes.
zur sicherheit ziehe ich immer 1000-5000bytes ab!

3. wenn es um PS (primär schlüssel) geht: GRÖSSTE vorsicht bei der
zugelassenen zeichen!
\x22 ist grosses gift!
komischerweise klappt ein PS bei \x23 oder \x24 nicht ein! also
erlaubt!
auch \xff ist gift!
== was ich bei 3. nicht untersucht habe, dürfen die verbotenen zeichen
NICHT an 1. stelle des zu gestaltenden PS stehen, und dürfen aber
irgendwo dahinter stehen (im rest?). ich codiere sicherheitshalber
jedes derzeichen, egal wo es steht.

evtl gibt es noch weitere grenzen, mir fallen sie nur nicht gerade ein
;-)



>> Und werden mehrfach auftretende Worte als einzelne Schlüssel gezählt, oder heißt der obige Satz, dass jeder Schlüssel auch mehrfach vorkommen darf?
oooh. bis ich das kapiert hatte.... ;-)
will sagen: es ist ein sehr gutes feature! die einmaligkeit im index!


> Pro Satz kann ein Schlüssel prinzipiell nur einmal auftreten. Ganz platt gesagt,
> auch ein Wort, das im Datensatz zigmal vorkommt, das kommt nur einmal in den Index.
> Mehrere identische Schlüssel für einen Satz wären ja wohl kaum hilfreich, sowas haben
> wir seit Anbeginn ausgeschlossen.
> B.E.


grüße, ihr klaus lehmann


-- 
Mit freundlichen Grüßen,
Ihr Klaus Lehmann
http://allegronet.de * eMail: allegronet at t-online.de * phone: 03528-452 807(fax 809) * mobil: 0171-953 7843
allegronet.de * Klaus Lehmann * D-01454 Radeberg * Bahnhofstr. 1
zuständiges Finanzamt: FA Hoyerswerda; zuständige Kammer: IHK Dresden;
zuständige Aufsichtsbehörde: Gewerbeamt Radeberg; USt-IdNr: DE247550760
Für den schnellen Geldverkehr: http://PayPal.Me/LehmannKlaus
* Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
* Bereits 4x allegro-utf8. Buchen Sie die allegro-Roadshow. Yes we can!
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 mit VuFind
* 2011: Sponsor der Peter-Sodann-Bibliothek (Staucha)
* 2013-2016: Bolero 64bit+allegro-zdb+eBooks-allegro-imd
Seit 2015 Spezialist in real Big Data! Beispiele: allegro-zdb&allegro-imd
Lesen Sie auf http://portal.allegronet.de/allegrowerkstatt/allegro-windows die
Wahrheit zur Zukunft von allegro-C. Bilden Sie sich Ihre eigene Meinung! Lesen Sie!





Am Freitag, 18. November 2016 um 09:01 schrieben Sie:
>> Gesendet: Freitag, 18. November 2016 um 08:38 Uhr
>> Von: "Fischer, Thomas" <fischer at sub.uni-goettingen.de>
>> 
>> ich kann mit meiner Datenbank jetzt wieder arbeiten, offenbar war ein Speicherbereich zu klein eingestellt, um meine umfangreichen P/Q-Tabellen aufzunehmen.
> Also Sie haben in der CFG den mX-Wert erhöht? Wir empfehlen seit langem mX64000
> und das steht auch in der ausgelieferten $a.cfg. Normalanwender haben nichts zu befürchten.

>> Der Fehlermeldung konnte ich das allerdings nicht entnehmen.
> Das ist bei Speicherbereichsüberläufen leider ein nicht immer verhütbares Übel - das Programm
> hat manchmal schlicht keine Gelegenheit mehr, sich aussagekräftig zu beschweren. Wir müßten
> mal endlich alles in Java neu programmieren.

>> 
>> Jetzt kämpfe ich mit der Optimierung meiner Indexeinträge. Theoretisch sollten
>> pro Datensatz 1000 Schlüssel, 32000 Byte je Satz
>> (http://www.allegro-c.de/grenzen.htm) möglich sein. Wie kann ich sehen, ob das funktioniert?
> Nur, indem Sie mal einen Testsatz machen, der diese Grenzen gerade eben noch einhält.

>> 
>> Meine F7-Anzeige ist erheblich kürzer, fehlt dann etwas oder wird es nur nicht angezeigt?
> Es fehlt nix, alles wird angezeigt. Wie könnte ein Programm auch entscheiden, was es wegläßt
> oder warum sollte es in dieser Hinsicht etwas nicht anzeigen, was da ist? Oder fallen Ihnen
> in der F7-Anzeige Einträge auf, die da nicht erscheinen, aber erscheinen müßten?

>> Muss ich Maßnahmen ergreifen, um zu verhindern, dass ich diese Grenze überschreite?
> Mir sind keine Maßnahmen bekannt, die so etwas zuverlässig sicherstellen könnten. Es gibt,
> m.a.W., keine Einstellschrauben etwa in der Indexparameterdatei zum Begrenzen der
> Schlüsselzahl oder deren Gesamtumfang in Kilobytes. Kollege Lehmann hat ansonsten mal
> Tips gegeben für Giga-Banken.

>> Und werden mehrfach auftretende Worte als einzelne Schlüssel gezählt, oder heißt der obige Satz, dass jeder Schlüssel auch mehrfach vorkommen darf?

> Pro Satz kann ein Schlüssel prinzipiell nur einmal auftreten. Ganz platt gesagt,
> auch ein Wort, das im Datensatz zigmal vorkommt, das kommt nur einmal in den Index.
> Mehrere identische Schlüssel für einen Satz wären ja wohl kaum hilfreich, sowas haben
> wir seit Anbeginn ausgeschlossen.

> B.E.
> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro




Mehr Informationen über die Mailingliste Allegro