Re: [Allegro] problem mit import.exe bei großen datenbanken

So Mär 4 18:30:42 CET 2012

guten abend,
wichtiger nachtrag zu meinem beitrag von 16.48 (heute):

ich habe einen erfolgreichen gegentest gemacht.
mit der import16bit-exe 
=======================

ergebnis: KEIN fehler! 1,4Mill datensätze wurden geschrieben.
der inhalt sieth sauber aus.

resume: die import.exe (32bit) hat 'ne macke!
übergangslösung: import16bit.exe benutzen

ich helfe gerne, diese macke zu finden. wie kann ich helfen?
wir haben es mit "verdammt" großen ausgangsdateien zu tun. die kann 
(und will) ich nicht auf meinen server zum download zur verfügung 
stellen. warum nicht? das hochladen würde fast wohl tage dauern.

ein fall auf alle fälle für braunschweig!

gruß k.lehmann

Guten Tag [Frau/Herr] Klaus Lehmann,
danke für Ihre Nachricht.
Am Sonntag, 4. März 2012 um 16:48 schrieben Sie mir.
Ihre Nachricht finden Sie am Ende dieser eMail.

> Guten Tag allerseits, 

> wie jedes jahr, erzeuge ich für meine bibliotheken eine datenbank mit 
> den 6,1 mill. stammdatensätzen der DB: perso,körpi und schlagworte.
> die letzten jahre musste die erzeugung mit 16bit-werkzeugen 
> durchgeführt werden. dieses ist alles voll auf 32bit umgestellt.
> (das wird das letzte mal der fall sein, weil die DB ja ihr angbeot 
> völlig umstellt oder umgestellt hat.)

> nun passiert etwas merkwürdiges:
> ================================
> man kann das auf http://allegronet.de/import.jpg  (ca 1MB) sehr gut 
> sehen. ich habe das jpg NICHT als attachment hier in die email mit 
> reingepackt. wer will, muss also extern guggen ;-)

> das skrip, wo irgendwas in die hosen geht, lautet an dieser stelle:
> import -f5 -dc:\temp\dbc_2012.alg -idbgkddat
> -epa/c:\temp\GKDCDdt1.alg -ka x2 -s0 -m0 -v0 -h0

> die ausgangsdatei c:\temp\dbc_2012.alg ist 2,1GB groß. reines ascii. 
> es sind meines wissen keine schweinereien drin ;-) also: klare 
> trennungen usw.

> die sache läuft über einen filter: dbgkddat.aim
> exportiert wird dabei nach c:\temp\GKDCDdt1.alg

> und es passsiert:
> =================
> bei der 13,6millionsten zeile in der dbc_2012.alg. der letzte sauber 
> rausexportierte datensatz ist: Workshop on human green.... (rechts im 
> bild gut zu sehen).
> links im bild sieht man, wie der darauffolgende satz: deutschsprachige
> abaqus.... zerhackstückelt ankommt. 
> das feld mab2 "001" wird wohl nur übernommen.

> wat iss hier los? ich frage:
> =============================
> hat import.exe (32bit) sein fassungsvermögen erreicht?
> die 13,6millionste zeile wurde eingelesen.
> die 1,17millionste zeile (1 zeile=1 datensatz) wurde in gkdcddt1.alg 
> wurde geschrieben.

> das ganze konnte ich 2x zuverlässig reproduzieren!!!

> gegentests:
> ===========
> ich lasse jetzt gerade den teil des skriptes als 16bit import.exe 
> durchlaufen. statt einer halben stunde wird er wohl einige stunden 
> benötigen.... (das wäre "notlösung 1"). das ergebnis steht noch aus.

> als "notlösung 2" könnte ich mir vorstellen, die ausgangsdatei 
> dbc_2012.alg in 2 teile zu teilen.

> wenn die beiden notlösungen klappen, bedeutet es was????
> import.exe (32bit) ist NICHT in der lage, den job zu machen?
> nebenbei bemerkt: import16.exe habe ich die jahre vorher benutzt.....

> wenn beide notlösungen NICHT klappen, heisst das, der fehler MUSS in 
> der ausgangsdatei zu suchen sein.    hm.....

> viele grüße zum sonntage,
> 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 * Kleinwolmsdorfer Str. 37
* Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
* Bereits 4x allegro-utf8. Buchen Sie die allegro-Roadshow
* Yes we can. Only with allegro. Yes we do. Allways with allegro.
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 with VuFind
* 2011: Sponsor der Peter-Sodann-Bibliothek (Staucha)
* 2012: mit allegro-utf8 V3 und allegro-vufind auf der IFLA in Helsinki

Am Sonntag, 4. März 2012 um 16:48 schrieben Sie:
> Guten Tag allerseits, 

> wie jedes jahr, erzeuge ich für meine bibliotheken eine datenbank mit 
> den 6,1 mill. stammdatensätzen der DB: perso,körpi und schlagworte.
> die letzten jahre musste die erzeugung mit 16bit-werkzeugen 
> durchgeführt werden. dieses ist alles voll auf 32bit umgestellt.
> (das wird das letzte mal der fall sein, weil die DB ja ihr angbeot 
> völlig umstellt oder umgestellt hat.)

> nun passiert etwas merkwürdiges:
> ================================
> man kann das auf http://allegronet.de/import.jpg  (ca 1MB) sehr gut 
> sehen. ich habe das jpg NICHT als attachment hier in die email mit 
> reingepackt. wer will, muss also extern guggen ;-)

> das skrip, wo irgendwas in die hosen geht, lautet an dieser stelle:
> import -f5 -dc:\temp\dbc_2012.alg -idbgkddat
> -epa/c:\temp\GKDCDdt1.alg -ka x2 -s0 -m0 -v0 -h0

> die ausgangsdatei c:\temp\dbc_2012.alg ist 2,1GB groß. reines ascii. 
> es sind meines wissen keine schweinereien drin ;-) also: klare 
> trennungen usw.

> die sache läuft über einen filter: dbgkddat.aim
> exportiert wird dabei nach c:\temp\GKDCDdt1.alg

> und es passsiert:
> =================
> bei der 13,6millionsten zeile in der dbc_2012.alg. der letzte sauber 
> rausexportierte datensatz ist: Workshop on human green.... (rechts im 
> bild gut zu sehen).
> links im bild sieht man, wie der darauffolgende satz: deutschsprachige
> abaqus.... zerhackstückelt ankommt. 
> das feld mab2 "001" wird wohl nur übernommen.

> wat iss hier los? ich frage:
> =============================
> hat import.exe (32bit) sein fassungsvermögen erreicht?
> die 13,6millionste zeile wurde eingelesen.
> die 1,17millionste zeile (1 zeile=1 datensatz) wurde in gkdcddt1.alg 
> wurde geschrieben.

> das ganze konnte ich 2x zuverlässig reproduzieren!!!

> gegentests:
> ===========
> ich lasse jetzt gerade den teil des skriptes als 16bit import.exe 
> durchlaufen. statt einer halben stunde wird er wohl einige stunden 
> benötigen.... (das wäre "notlösung 1"). das ergebnis steht noch aus.

> als "notlösung 2" könnte ich mir vorstellen, die ausgangsdatei 
> dbc_2012.alg in 2 teile zu teilen.

> wenn die beiden notlösungen klappen, bedeutet es was????
> import.exe (32bit) ist NICHT in der lage, den job zu machen?
> nebenbei bemerkt: import16.exe habe ich die jahre vorher benutzt.....

> wenn beide notlösungen NICHT klappen, heisst das, der fehler MUSS in 
> der ausgangsdatei zu suchen sein.    hm.....

> viele grüße zum sonntage,
> ihr klaus lehmann