Re: [Allegro] problem mit import.exe bei großen datenbanken (es geht weiter!)

Mi Mär 7 19:18:06 CET 2012

etwas verspätet. gruß an alle interessierten....
bedauerlicherweise ist diese email nicht an die liste 
selbst gegangen. deshalb zur komplettietung zusätzlich an die liste.
obwohl die dinge sich wohl inzwischen zum guten geändert haben. dazu 
dann gleich später.

das schrieb ich heute um 07:37:

gut, ich habe mir ähnliches gedacht.
> Am 07.03.2012 07:37, schrieb Klaus Lehmann:
 >> und: ich habe mal folgendes gemacht:
 >> beim 32bit-versuch, habe mir die ausgangsdatei genommen, und alles
 >> herausgeschnitten, was ab der 1,17mill.sten zeile kaputt geht. als
 >> ergebnis erhalten wir eine datei. sie hat eine größe von
 >> 2.147.479.514 bytes.
 >> ist DAS die einlesegrenze vom 32bit-import.exe??? 16bit-import.exe
 >> kann wohl fehlerfrei größer!
> Das ist knapp drunter, 2GB sind 2147483648 Bytes. Weil bei einem Abbruch
> das Ende der Schreibdatei nicht mehr genau bis zur Abbruchstelle reicht
> (wegen der blockweisen Speicherung) sieht es also sehr danach aus, daß
> hier die 2GB-Grenze die Ursache ist.

ok, nehmen wir das mal an. es liest sich sehr, sehr plausibel.

aber warum arbeitet import16-bit.exe sauber an dieser stelle? 
ich habe sein ergebnis überprüft! keine fehler zu sehen. 
alelrdings: leider kann ich die komplette, millionen zeilen zählende, datei, nicht zu 100% überprüfen.

ich behaupte mal: 
(den soucecode nicht kennend und auch bestimmt nicht 
nach dem kennenlernen verstehend)
.... import16-bit.exe macht "es" anders. 
import16-bit.exe muss die zu verarbeitende datei anders(!) (wie?) einlesen! 
liege ich falsch?

zur unten notierten frage:
die aim ist eigentlich sehr einfach. hier mal auszugsweise der inhalt:
info noch: die 2GB-einzulesende datei ist eine reine ascii-datei (ich glaube mit 
zeilenende 13 10, kann's gerade nicht bestätigen)

re=10 10
  ca 30 y-befehle   
_11
_73 74
y .246 12
_12
_105 106

  einige p-befehle (ca 15x)
  ca 10x y-befehle
....
y .30 0
_ 13 10
_ 0

_ 13
_ 0

_ 10
_ 0

usw.

diese aim funktioniert seit ca 5 jahren so, fast ohne änderungen.
die einzige änderung: import32bit.exe

> Es kommt aber drauf an, welcher Einlesemodus verwendet wird.
> Das problematische  fseek(...)  tritt nur in Aktion, wenn es einen
> Befehl re=... gibt, aber auch dann nicht immer. In Unkenntnis der Daten
> und Parameter kann ich es weder genauer sagen noch zwecks Verbesserung
> testen.
ja, "re" hat mir in vergangenheit bei anderen aufgaben auch schon sehr 
oft kopfzerbrechen bereitet....

> Beispielsweise bei einer CVS-Datei mit Tab als Delimiter und
> re=13 10
unsere zu importierende datei ist keine csv.
bei der gelegenheit: hier mal ein auszug aus der 2gb-ascii-datei:

der erste datensatz:
### 00001nM2.01200024      p
001 100028926
002a19900615
003 20080405153151
020a100028926Î0000
030 |z1i||l||||||
065 b|||
068afÎa
068d12
068ev
070 0000
070aDNB
070b9999
079reDE-12
079rrDE-12
079n3
800 Barth, Joachim
816 Barth, Joachim: Elegia gratulatoria in nuptias Pauli Sculteti et Annae Furmannae scripta. - 1550

mal als hex dargestellt (am ende sind einige 0a0d's zu erkennen)
2323232030303030316E4D322E3031323030303234202020202020700D0A303031203130303032383932360D0A3030326131393930303631350D0A3030332032303038303430353135333135310D0A30323061313030303238393236CE303030300D0A303330207C7A31697C7C6C7C7C7C7C7C7C0D0A30363520627C7C7C0D0A3036386166CE610D0A3036386431320D0A30363865760D0A30373020303030300D0A30373061444E420D0A30373062393939390D0A303739721F6544452D31320D0A303739721F7244452D31320D0A3037396E330D0A3830302042617274682C204A6F616368696D0D0A3831362042617274682C204A6F616368696D3A20456C656769612067726174756C61746F72696120696E206E757074696173205061756C69205363756C7465746920657420416E6E6165204675726D616E6E616520736372697074612E202D20313535300D0A0D0A0D0A0D0A

> würde es wohl nicht passieren. Es sei denn, das Programm kann
> grundsätzlich, also vom Betriebssystem her, eine längere Datei nicht
> jenseits 2GB lesen, auch nicht rein sequentiell. Das weiß ich nicht,
> aber dann sähe es ganz finster aus. Nein, nicht ganz, man müßte die
> Ausgangsdatei dann zuerst in zwei Hälften teilen.

das wäre eine notlösung.
nur wie teilt man eine datei, ohne daß inhalte "kaputtgehen"? 
will sagen: woher weiss das teilungsinstrument, wann ein datensatz ZU ENDE 
ist? sicher, ich kenne teilerwerkzeuge, denen kann man sagen, ab 1.000.000 
zeilen, mache eine neue datei (in allegro müsste ein solches tool 
enthalten sein...)
es wäre eine notlösung, die auch natürlich in einer 
skriptgesteuerten umgebung laufen MUSS ;-)   

viele grüße
ihr klaus lehmann

ps: zum indexproblem der großendatenbank komme ich wohl leider erst ab 
16.00 Uhr heute...
[nachtrag von heute abend: diese email wird sich bis morgen 
verzögern....]

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

Am Mittwoch, 7. März 2012 um 08:15 schrieben Sie:
> Am 07.03.2012 07:37, schrieb Klaus Lehmann:

 >> und: ich habe mal folgendes gemacht:
 >> beim 32bit-versuch, habe mir die ausgangsdatei genommen, und alles
 >> herausgeschnitten, was ab der 1,17mill.sten zeile kaputt geht. als
 >> ergebnis erhalten wir eine datei. sie hat eine größe von
 >> 2.147.479.514 bytes.
 >> ist DAS die einlesegrenze vom 32bit-import.exe??? 16bit-import.exe
 >> kann wohl fehlerfrei größer!
 >>
> Das ist knapp drunter, 2GB sind 2147483648 Bytes. Weil bei einem Abbruch
> das Ende der Schreibdatei nicht mehr genau bis zur Abbruchstelle reicht
> (wegen der blockweisen Speicherung) sieht es also sehr danach aus, daß
> hier die 2GB-Grenze die Ursache ist.

> Es kommt aber drauf an, welcher Einlesemodus verwendet wird.
> Das problematische  fseek(...)  tritt nur in Aktion, wenn es einen
> Befehl re=... gibt, aber auch dann nicht immer. In Unkenntnis der Daten
> und Parameter kann ich es weder genauer sagen noch zwecks Verbesserung
> testen.
> Beispielsweise bei einer CVS-Datei mit Tab als Delimiter und
> re=13 10
> würde es wohl nicht passieren. Es sei denn, das Programm kann
> grundsätzlich, also vom Betriebssystem her, eine längere Datei nicht
> jenseits 2GB lesen, auch nicht rein sequentiell. Das weiß ich nicht,
> aber dann sähe es ganz finster aus. Nein, nicht ganz, man müßte die
> Ausgangsdatei dann zuerst in zwei Hälften teilen.

>> und wenn wir weiterhin in die zukunft schauen wollen, dann sollten wir
>> uns überlegen, wie wir allegro nach vorne (wieder!) bringen
>> wollen/müssen.
>> z.b. in dem Braunschweig !endlich! Öffentlichkeitsarbeit
>> (oder benutzen wir doch das schimpfwort "marketing") macht.
>> auf diesem gebiet passiert schlichteweg nichts.
>>
> Aus Gründen, die wir schon mal erörtert hatten und die außerhalb meiner
> Einflußsphäre liegen.
> Andererseits gilt auch das Betreiben einer Homepage als, wenn auch eher
> passive, Öffentlichkeitsarbeit.

> MfG B.E.

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

===8<============== Ende des Original Nachrichtentextes =============

-- 
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 AllegroC
* 2011: Sponsor der Peter-Sodann-Bibliothek (Staucha)
* 2012: allegro-utf8 V3 auf der IFLA in Helsinki

Klaus                            mailto:lehmann_klaus at t-online.de