[Allegro] kleine beobachtung: acon/avanti. in zusammenarbeit mit update.job(thb) evtl auch update.job(allegro-C)

[Klaus Lehmann]

Guten Tag allerseits,

will das mal mitteilen. vielleicht ist es für andere wichtig, in den
meisten fällen wohl nicht ;-)


es geht um große datenmengen!

bin mal wieder am erzeugen....
eine bibliothek soll eine übersicht bekommen, was alles an
zdb-datensätzen vorhanden ist. "normalerweise" ging das immer fix,
aber jetzt gibt es seitens der datenlieferanten ein problem: die
auslieferung der zweiten zdb-halbjahrsdaten verzögert sich um 2 monate, so
daß man mit den wöchentlichen lieferungen auskommen muss!
ziel ist: ein komplettabzug für die bibliothek zyx!
habe ich einen komplettabzug, der normalerweise 2x im Jahr erscheint,
muß ich weniger einzellieferungen der wochen nehmen, und es geht
schneller! genug der vorrede ;-)
nee, doch noch ein paar zahlen: derzeit bin ich in der 29.woche!
ziel ist die 45.Woche! ;-)
also noch 16 wochen mit einer laufzeit von je knapp einer halben stunde ;-)


da passiert etwas, was mich verwirrt hat. was fehler erzeugt hat. ohne
grund. scheinbar:
mit dem befehl
acon.exe -jupdate-thb.job -ka -fm11 -dzdb -uzdb-titel.alg -n150 -F0/0 -L
wird der jeweils neue datenbestand aus der datenlieferung in die
große datenbank (1,88 Mill Datensätze) reingesetzt

schauen wir auf die -n150 !
da ist das problem!
bislang, wenn die datenbank nicht zu "groß" wurde (sie ist ja schon
beängstigend groß), war -n NIE ein problem.
aber derzeit gibt es datenmassen, die eingespielt werden müssen!


will auf den punkt kommen!
-n150  !
alles was noch nicht vorhanden ist, also NEU, kommt in die -n150
die interna der api sagen: 16MB, mehr darf eine ald nicht wiegen!
tja. die zdb_150.ald wurde fetter und fetter (kam mir persönlich
bekannt vor ;-)
sie erreichte die größe von 16MB.
ich deuchte, sie wird von zdb_150.ald auf die noch nicht vorhandene
zdb_151.ald wechseln. Niente! irgendwann erreichte sie die größe von
17MB. und dann regnete es fehler! schreibfehler. diese konnte man in
der log verfolgen (NICHT in der zdb.log! sondern in der log vom
update-verfahren!)


konstantieren wir: (ist das deutsche verb von Konstanz?)
der update.job von theo berger kann das nicht!
ich vermute, der allegro'sche update.job auch nicht!
nur ne vermutung! (zeit zum testen habe ich nicht ;-)
wiederholung: was wir von presto/a99 kennen, gewohnt sind:
ist eine ald-datei voll, wird eine nächste leere eröffnent!


derzeitige lösung, das leben muss weitergehen!
mit einer for-schleife erfahre ich meine datenlieferungsnummer der
zdb. und bestimme dann ganz automatisch die zu setzende -n150
bis -n155 will ich maximal gehen.
der testlauf über nacht verlief bislang ruhig. es traten keine
sagenwiresmalso "-n150-fehler" auf (wo sie hätten auftreten können)!


also: wer sowas macht, daten in eine mit -n bestimmte datenbanknummer
schiebt, UND das mit update.job, der muss mal schauen. ist die -150
übervoll? dann muss er sich was ausdenken! ;-)


grüße nach einer kurzen nacht
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-12:  Sponsor: Peter-Sodann-Bibliothek+IFLA:allegro-utf8
* 2013-14: Bolero 64bit.+allegro-zdb: endlich. + eBooks
* 2015-16: allegro-vufind.+ allegro-imd.Die weltgrößte(?) Filmdatenbank
* 2017-18: Exporte. Marc und Co.  Marc ist sehr different
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!