[Allegro] indexierung mit allen decimal-werten, die das betr.system zu bieten hat?

[Klaus Lehmann]

Guten Tag Herr Eversberg,
danke für Ihre Nachricht.
Am Montag, 18. Mai 2015 um 13:28 schrieben Sie.
Ihre Nachricht finden Sie am Ende dieser eMail.
> Am 18.05.2015 13:00, schrieb Klaus Lehmann:
>>> Man braucht im übrigen die Länge des Schlüssels nicht explizit
>>> anzugeben mittels  e246 oder so, denn er wird bei der mit il=...
>>> angegebenen Länge gekürzt.
....
>> nee, nee. ich habe einen zusammenbruch acons' erlebt.
>> mit fehlermeldung des betriebssystems.
>>
> Das hätten Sie mal gleich anbringen sollen, dann wär's jetzt weg,
> wär kein Problem gewesen. Jetzt heißt's warten bis V35.6, oder in
> update.job die Zeilen
> var p
> var (e"=")
> ins $primkey
> ersetzen durch
> var p
> var (0,246 e"=")
> ins $primkey

allergrößten dank!


viele grüße,
ihr klaus lehmann



...
> Das sind nur erste Vorübungen des aufstrebenden Nachwuchses für die Welt
> der "Linked Open Data", was eben eine sehr komplexe Sache ist. Aber die
> ist angesagt und im Kommen - und sonst nichts. Daher *wird* die auch
> kommen, nur eine Frage der Zeit, und "too big to fail".

>> und: immer mehr kommen daten"banken" mit grossen inhalten...
>> bin mal gespannt, wann die grenze von 8000 bytes aufgebrochen wird,
> Ist sie schon, ein Feld kann 10.000 Bytes lang sein. Steht in "Grenzen,
> Schranken, Barrieren".
ja, ich erinnere mich. vor 1-2 jahren war das mal thema.
> Erweiterung auf 32.000 scheitert nur an der noch für nötig gehaltenen
> PRESTO-Kompatibilität. (Wobei für PRESTO auch 8,000 schon nicht mehr
naja.... ich weiss nicht wann es soweit sein wird, aber wagen wir mal 
einen blick in die kristallkugel der möglichkeiten:

1. wenn alle(?) nur noch 64bit-betr.system haben, dann ist presto weg vom 
fenster
2. wenn die dos-basis für die datenbank, die auch noch auf 16bit 
basiert, nicht mehr ausreichend ist, weil man eben doch alle 
(un)schönen europäischen so.-zeichen reinhaben möchte; dann wird es 
die dos-basis nicht mehr geben, dann brauchen wir zwangsläufig die 
32bit-fähigkeit
[ich verliere jetzt schon die übersicht, WAS ist WO codiert, WAS muss 
ich im internet umcodieren, WELCHE tabellen muss ich benutzen, um das 
und das ergbniss zu bekommen...]
3. bei der ganzen überlegerei, soltle man die linuxbrüder und 
-schwestern nicht vergessen....
ach, das sind gedanken. aber irgendwann wird es ernst werden....


> wirklich handhabbar sind, das ganze Fenster faßt ja nur 2000 Zeichen.)

> B.E.



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



-- 
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
* 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)
* 2012: mit allegro-utf8 V3 und allegro-vufind auf der IFLA in Helsinki
* 2013: Bolero 64bit. Fußige Noten aufgeblättert (=Die Fußnotendoku)
* 2014: allegro-zdb: endlich. Die Wiedervereinigung! + eBooks
* 2015: allegro-vufind. Endlich! Noch moderner! Web2 auch für Ihren Katalog?





Am Montag, 18. Mai 2015 um 13:28 schrieben Sie:
> Am 18.05.2015 13:00, schrieb Klaus Lehmann:

>>> Man braucht im übrigen die Länge des Schlüssels nicht explizit
>>> anzugeben mittels  e246 oder so, denn er wird bei der mit il=...
>>> angegebenen Länge gekürzt.
>>
>> nee, nee. ich habe einen zusammenbruch acons' erlebt.
>> mit fehlermeldung des betriebssystems.
>> acon crashte genau an der stelle, wo der primäre schlüssel um die 260
>> war. da muss also ein (seltenes) problem noch in acon (?oder?
>> update.job stecken...) ?!
>> deshalb begrenze ich den primären schlüssel auch mit e246, sicher ist
>> sicher ;-)
>>
> Das hätten Sie mal gleich anbringen sollen, dann wär's jetzt weg,
> wär kein Problem gewesen. Jetzt heißt's warten bis V35.6, oder in
> update.job die Zeilen

> var p
> var (e"=")
> ins $primkey

> ersetzen durch

> var p
> var (0,246 e"=")
> ins $primkey

>>
>> naja. man erkennt immer mehr und mehr, daß "man" allegro für
>> vielerlei aufgaben nutzen kann. ich habe es z.b. längst genutzt, wenn
>> ich an den xml-strukturen verzweifelt bin. ich weiss nicht mehr genau,
>> wo das war, aber "unsere" helden der inetbib-liste sind ja immer "stolz
>> wie bolle", wenn sie ihre bibliotheksdaten als opensurze
>> (de)klassifizieren. bloss mit dem müll, der da präsentiert, kannman
>> meistens nichts anfangen DAS ist aber NUR meine meinung.
>>
> Das sind nur erste Vorübungen des aufstrebenden Nachwuchses für die Welt
> der "Linked Open Data", was eben eine sehr komplexe Sache ist. Aber die
> ist angesagt und im Kommen - und sonst nichts. Daher *wird* die auch
> kommen, nur eine Frage der Zeit, und "too big to fail".

>> und: immer mehr kommen daten"banken" mit grossen inhalten...
>> bin mal gespannt, wann die grenze von 8000 bytes aufgebrochen wird,
> Ist sie schon, ein Feld kann 10.000 Bytes lang sein. Steht in "Grenzen,
> Schranken, Barrieren".
> Erweiterung auf 32.000 scheitert nur an der noch für nötig gehaltenen
> PRESTO-Kompatibilität. (Wobei für PRESTO auch 8,000 schon nicht mehr
> wirklich handhabbar sind, das ganze Fenster faßt ja nur 2000 Zeichen.)

> B.E.



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