[Allegro] kleiner Bericht aus der allegroWerkstatt: Thema: große&exakte Primärschlüssel

[Klaus Lehmann]

Guten Tag allerSeits,


für mein projekt: allegro-imd
rücke ich vom großen und exakten Primärschlüssel ab!
[exakt=buchstabengetreu! OHNE manipulation]


warum?
die idee war doch gut!
z.B. je exakter, desto genauer


(eigene)antworten:
1. meine sonderzeichenliste, bzw die liste der satzzeichen, wurde auf
75 zeichen aufgestockt. jedes zeichen wurde durch eine 6stellige kombi
ersetzt. das hat platz gefressen!
UND satzzeichen, wie ",:-= usw usw, die am am anfang des HST standen,
waren immer schädlich (also mussten sie ersetzt werden!); teilweise,
wenn sie mitten im text vorkamen (ich erinnere mich: das "="), das
fanden acon und der PS das auch NICHT immer gut!
man musste immer MEHR aufpassen, und testen, testen, testen.


2. jetzt kehre ich "reumütig" zur idee von BS zurück!
warum?
sonderzeichen, die für den indexaufbau/erzeugung des PS gefährlich
werden, werden automatisch unterdrückt. ich hoffe -nebenbei- sehr, daß
ich diese sonderzeichen NICHT nicht für die unterscheidung im PS
benötige. wir weden sehen.

so wird der PS aussehen:
i1=0
i2=0
i3=0
i8=62       >        Steuerz. f. Umblaettern bei Enter
i9=62 61    >=       bzw. bei <Cursor rechts>
ic=1           nur wenn Umcodierung der Eingabe gewuenscht
il=246         Schluessellaenge (frueher 72)    achtung! 2015/08 wenn in update.job ein höherer wert steht, wird dieser bei einem update genommen!
                                                    var p;var (0,246 e"=" F" ");ins $primkey
ii=12           grüße der alds 12x16GB
...
#-@
!00 y2 e246 p"|9"
#+#

so. damit habe ich /endlich wieder?/ die indexeinträge in klein und
ohne irgendwelche gefährlichen sonderzeichen.

mal schauen....
die tests laufen gerade gut!


ich denke, EIN problem bleibt weiter bestehen.
die maximumgröße des HST's liegt derzeit bei 500bytes. also fast
doppelt soviel wie "erlaubt". bislang scheint folgendes NICHT zu
klappen: ein abgleich mit -fm41 und update.job. obwohl die ersten
246-250 zeichen garantiert GLEICH sind, wird der upzudatende(blödes
wort!) NICHT eingespielt, er landet in der datei, die durch -n
definiert wird.. für DIESES problem muss ich mir was ausdenken.....:
es gibt da so tgeile des sog. HST, der ist in {} gepackt. der scheint
NICHT wichtig zu sein, man köntne also durch api-befehle die
konstruktion des PS innerhalb {} vielleicht unterbinden.... mal
schauen. ist wie gesagt NICHT superwichtig: es sind 26 datensätze von
3 Mio's ;-)

viele 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
* 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?