[Allegro] anzeige von einem hfm-feld in apr geht nicht(?) (weitere anmerks zu: BigData mit allegro-C)

Mi Dez 2 09:42:33 CET 2015

Guten Tag Morgen Herr Eversberg,
danke für Ihre Nachricht.
Am Mittwoch, 2. Dezember 2015 um 08:17 schrieben Sie.
Ihre Nachricht finden Sie am Ende dieser eMail.

herr berger hat ja schon treffend und viel tiefergehend als olle icke
analysiert (DANKE dafür!).

wie ich schrieb, funktioniert DAS:
"gegen die lösung mit
#23. p{ C C t79 "Abkürzungen: BT=  CP=  SD=  " t122 } e0
habe ich derzeit nichts!"

nach dem Punkt mit etwas vierstelligem funktioniert es nicht!
> Die Analyse ergibt folgendes:
> Eine Exportzeile
> #xy.nnnnnn
> verträgt nur dann irgendwelche Zusätze, also Manipulationsbefehle
> und/oder bedingten Sprung, wenn die Zahl hinter dem . kleiner als
> 1000 ist, also weniger als 4 Stellen hat.

gut, ist wenn mann's weiss! (-> bitte in die doku!)

> Zum Glück gibt's Abhilfen, sogar 3 Stück:
> 1. Inhalte, die eine Behandlung der kritischen Art erfordern,
>     nicht auf 4- oder mehrstellige HFM-Nummern legen, sondern
>     in den Bereich unter 1000.
> 2. Für die fraglichen Inhalte eine andere Kategorienummer
>     wählen und diese nur mit HFM-Nummern unter 1000 belegen.

warum ich erstmal vierstelliges in der ziellinie hatte, ist ganz
einfach. erinnern wir uns an einige monate zuvor:
da schrieb ich dazu auch einiges. ich will das nochmal kurz zur sprache
bringen:
wenn ich weiss, daß ich viele inhalte REINbekomme, gestalte ich die
datenbank so, daß das hfm-feld mit .1000 belegt werden kann! gehe ich
mit update ran, und treffe KEINE vorkehrungen, schiebe ich also
inhalte rein, in ein hfm-feld, fängt es an mit hfm.1 und zählt sich
durch. NICHT schön! dann habe ich zählende reihenfolgen, wie
1,10,111,2,usw usw 1000.
da ich ein PREUSSE bin (ja, in berlin -> GENAUER spandau geboren!),
treffe ich vorkehrungen: ein hfm-feld ist bereits da, mit unnützem
inhalt wie zyx: #hfm.0999 xyz (das wird später gelöscht!). kommen
jetzt nun inhalte z.b. mit update rein, bekommen sie wie die
preussischen zinnsoldaten, hfm-bezeichner: .1000 als ERSTES neues
feld, danach 1002 usw usw. keinen MIST wie hfm.1 oder hfm.99 ;-)
alles Klar(o)?

deshalb:
#23.1000 p{ C C t79 "Abkürzungen: BT=  CP=  SD=  " t122 } e0
geht nun nicht, und ist verstanden.

> 3. Für die fraglichen Inhalte eine andere Kategorienummer
>     wählen und für diese gar keine HFM-Nummern verwenden, sondern
>     nur normale Mehrfachzeichen.

jrünau! (berlinisch für "genau"):
#23. p{ C C t79 "Abkürzungen: BT=  CP=  SD=  " t122 } e0

dann isset der anzeige völlich ejal, wat nu an den #23'ern vorhanden
iss. hauptsache EIN feld ;-)

> Wir denken, daß niemand, auch Koll. Lehmann nicht, ganz bestimmte
> 4- oder mehrstellige HFM-Nummern mit individueller Semantik
> unabdingbar braucht. Es steht ja im Gegenteil immer noch die
> rigorose und durchaus vertretbare Position im Raum, HFM-Nummern
> niemals mit Semantik zu befrachten! Dann enstünde erstens das
bitte, was ist "semantik"? keene ahnung, nich....

> Problem nicht, aber zweitens bliebe für ganz seltene Ausnahmen
> immer noch die Abhilfe 3.

> Kollege Lehmann steht somit nicht rettungslos im Starkregen, aber
> mit gelegentlichen Schauern müssen Extremsportler fertig werden.
ach, was habe ich schon für duschen erlebt. jetzt ackere ich schon 1
halbes jahr an allegro-imd. und es wird immer schöner!
der letzte hurricaine war: als die felder IMMER größer wurden, über
16kb flossen. die datensätze immens länger als 220kb wurden. es drohte
ELBE-hochwasser! allegroimd stand landUNTER! und kein helmutschmidt in
sicht! (nu isser von uns jejangen....)
AUCH diese kritische situation wurde geMEISTERt.

so ist ein "selbstreparierer" geschrieben worden, der INNERHALB der
kompiliationsphase auf überlange datenfelder und datensätze schaut,
sie findet und dokumentiert, und sie automatisch "repariert": also aus
ihnen z.b. 2 datensätze macht. was ich eben NICHT gebrauchen kann: ist
störung! dumme fragen (von allegro), ob ich das und jenes will. und
das und jenes defekt ist. das stört den ablauf.

übrigens: vor ca 1-2 wochen schrieb ich über BIG-Data. nachtrag dazu:
fliessen mal so 500.000 bis 1.000.000 datenfelder in die datenbank
rein, möchte sie INDEXIERT werden! wer das nicht macht, update.job
wird extrem langsam! alles das muss autamatisch fungsionieren....

viele grüße
ihr klaus lehmann

> B.E.

-- 
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 Mittwoch, 2. Dezember 2015 um 08:17 schrieben Sie:
> Am 01.12.2015 um 16:51 schrieb Thomas Berger:
>> Am 01.12.2015 um 16:14 schrieb Klaus Lehmann:
>>
>>> ist da was falsch?
>>>
>>> Man kann es an der Demo-Datenbank ausprobieren:
>>>
>>> #gn.150000 +? { t79 " .150000 Sach-SW: " t65 } ,"_\031g_ / _" #zz 122
>>> ...
>>> Erst bei #gn.150 ist alles so wie erwartet.
>>>

> Vorweg: Normalanwender sind unbetroffen, auch solche, die das Feld
> #gn für GND-Sätze anwenden.
> Nur Extremsportler müssen weiterlesen.

> Die Analyse ergibt folgendes:
> Eine Exportzeile

> #xy.nnnnnn

> verträgt nur dann irgendwelche Zusätze, also Manipulationsbefehle
> und/oder bedingten Sprung, wenn die Zahl hinter dem . kleiner als
> 1000 ist, also weniger als 4 Stellen hat.

> Das kann man mißlich finden oder skandalös, und wir wollen das auch
> gar nicht mit einem "so isses eben!" abtun.
> Wir können aber auch nicht, so knapp vor Festschreibung, schnell
> noch eben einen Nachbesserungsversuch machen, denn die Export-
> parameter-Abarbeitung ist eine extrem komplexe Angelegenheit, daher
> sind Eingriffe immer riskant und erfordern extensives Testen.

> Zum Glück gibt's Abhilfen, sogar 3 Stück:

> 1. Inhalte, die eine Behandlung der kritischen Art erfordern,
>     nicht auf 4- oder mehrstellige HFM-Nummern legen, sondern
>     in den Bereich unter 1000.

> 2. Für die fraglichen Inhalte eine andere Kategorienummer
>     wählen und diese nur mit HFM-Nummern unter 1000 belegen.

> 3. Für die fraglichen Inhalte eine andere Kategorienummer
>     wählen und für diese gar keine HFM-Nummern verwenden, sondern
>     nur normale Mehrfachzeichen.

> Wir denken, daß niemand, auch Koll. Lehmann nicht, ganz bestimmte
> 4- oder mehrstellige HFM-Nummern mit individueller Semantik
> unabdingbar braucht. Es steht ja im Gegenteil immer noch die
> rigorose und durchaus vertretbare Position im Raum, HFM-Nummern
> niemals mit Semantik zu befrachten! Dann enstünde erstens das
> Problem nicht, aber zweitens bliebe für ganz seltene Ausnahmen
> immer noch die Abhilfe 3.

> Kollege Lehmann steht somit nicht rettungslos im Starkregen, aber
> mit gelegentlichen Schauern müssen Extremsportler fertig werden.

> B.E.

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