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

[Klaus Lehmann]

guten abend herr eversberg, 
falls ich nicht alle fakten genannt hatte, lieber nochmal
die alg, aus der alles rausgezogen mit import32bit wird, ist 2,2GB 
groß.

hier die genauen zahlen:
03.03.2012  05:18     2.228.075.861 DBC_2012.ALG
04.03.2012  18:16       306.838.348 GKDCDdt1.alg-16bit
05.03.2012  20:10       255.936.058 GKDCDDT1.alg-32bit

aus dieser 2,2GB großen datei wird mit einer aim-datei etwas 
importiert. 
wenn ich die import32.exe nehme, dann entsteht eine datei 
mit dieser größe: 255.936.058
inhalt ist zerhackstückelt, wie auf http://allegronet.de/import.jopg 
zu sehen ist. der nachfolgende rest ab zeile 1,17mill ist kaputt.


wenn ich die import16.exe nehme, dann entsteht eine datei 
mit dieser größe: 306.838.348 bytes.
der inhalt ist "absolut" (naja, man kann schlecht 1,4Mill zeilen 
durchschauen...) sauber. 
ab der 1,17mill. zeile ist kein fehler 
zu entdecken. insgesamt hat diese datei 1,4Mill zeilen. die datei aus 
dem jahr war 262MB groß. ein wachstum von ca 12% ist für mich logisch.



nochmal: es wird aus einer 2,2GB datei rausgelesen.
wenn ich import32.exe nehme, habe ich sehr "weit hinten" einen unfall. 
alles ab danach ist kaputt.
wenn ich import16.bit nehme, habe ich (bin ziemlich sicher) einen 
sauberen importvorgang.


also: WO ist das problem?
kann import23bit nicht aus einer 2,2GB lesen?
warum kann import16bit.exe es?
es geht um die größe der einzulesenden datei, richtig?



und: ich habe mal folgendes gemacht:
beim 32bit-versuch, mir die ausgangsdatei genommen, und alles 
herausgeschnitten, was ab der 1,17mill. zeile kaputt geht. als 
ergebnis erhalten wir eine datei, die import32bit.exe wohl sauber 
einlesen kann: sie hat eine größe von 2.147.479.514 bytes.
ist DAS die einlesegrenze vom 32bit-import.exe???



gruß klaus lehmann







 
 
Guten Tag [Frau/Herr] Bernhard Eversberg,
danke für Ihre Nachricht.
Am Montag, 5. März 2012 um 07:49 schrieben Sie mir.
Ihre Nachricht finden Sie am Ende dieser eMail.

> Am 04.03.2012 20:19, schrieb Thomas Berger:
....
> Das 16bit-Programm ist an der Stelle identisch. Kann Herr Lehmann mal
> prüfen, ob seine Ergebnisdatei, die es erzeugt hat, an der Nahtstelle
> von 2GB korrekt ist? Vermutlich demnach nicht.
> 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 * 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 Montag, 5. März 2012 um 07:49 schrieben Sie:
> Am 04.03.2012 20:19, schrieb Thomas Berger:
>>
>> Aber gewisse Funktionen in der 32bit-Library (speziell fseek() )
>> koennen nur Positionen im Bereich -2^31 .. 2^31. Fuer groessere
>> Dateien gibt es evtl. andere Funktionen, auf die ausgewichen werden
>> kann.
>>
>> Das 16bit-Import.exe macht evtl. keine fseek(), das 32bit-Programm
>> macht ausweislich des Quellcodes welche. Argumente dafuer sind
>> vom Typ (signed) "long", das ist auf der Plattform Visual C++ 2005
>> ein 32bit Integer. See?
>>
> Das 16bit-Programm ist an der Stelle identisch. Kann Herr Lehmann mal
> prüfen, ob seine Ergebnisdatei, die es erzeugt hat, an der Nahtstelle
> von 2GB korrekt ist? Vermutlich demnach nicht.

> Es gibt im Visual C++ eine Funktion
>    __int64 _lseeki64( int handle, __int64 offset, int origin );

> Aber kennt GNU C++ Vergleichbares?

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