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

[Bernhard Eversberg]

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.