Maximale DBF Größe mit 1.90.355

Zugriff, Engines, Konvertierung. Von ADS über DBF bis zu SQL.

Moderator: Moderatoren

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15696
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 66 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Maximale DBF Größe mit 1.90.355

Beitrag von brandelh »

Hi,

Die Dokumentation ist sich nicht einig über die maximale Dateigröße unter Xbase++
Sicher ist, dass man für mehr als 1 GB DBF Dateien etwas tun muss, ähnlich wie unter Clipper auch.
Allerdings wird nichts gelinkt, sondern so der Datenbanktreiber (hier NTX) angepaßt:

Code: Alles auswählen

#include "DMLB.CH"
#include "DBFDBE.CH"
#include "ntxdbe.ch"
... im Code oder in der DBESYS ...
   DbeInfo( COMPONENT_DATA,  DBFDBE_LOCKOFFSET, 0x7FFFFFFF )   // nötig für 2GB Dateien
   DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET, 0x7FFFFFFF )
   DbeSetDefault( "DBFNTX" )
nun steht ab und zu in der Doku aber auch der für 4 GB oder 2,4 GB Wert ... gibt es da Unterschiede ?

Code: Alles auswählen

? "Angefordert mit 0xFFFFFFFF"
DbeInfo( COMPONENT_DATA,  DBFDBE_LOCKOFFSET, 0xFFFFFFFF )  // gibt das 4 GB Dateien ? 
DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET, 0xFFFFFFFF )
? "Angefordert mit 0x7FFFFFFF"
DbeInfo( COMPONENT_DATA,  DBFDBE_LOCKOFFSET, 0x7FFFFFFF )  // nötig für 2 GB Dateien
DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET, 0x7FFFFFFF )
Mit diesem Programm habe ich es mit 1.90.355 getestet:

Code: Alles auswählen

#include "XBP.CH"
#include "DMLB.CH"
#include "DBFDBE.CH"
#include "ntxdbe.ch"
#include "Error.ch"

PROCEDURE DbeSys()
   IF !DbeLoad( "DBFDBE", .T. )
      ALERT( MSG_DBFDBE_NOT_LOADED, { "OK" } )
   ENDIF
   IF !DbeLoad( "NTXDBE", .T. )
      ALERT( MSG_DBFDBE_NOT_LOADED, { "OK" } )
   ENDIF
   IF !DbeBuild( "DBFNTX", "DBFDBE", "NTXDBE" )
      ALERT( MSG_DBFNTX_NOT_CREATED, { "OK" } )
   ENDIF
   DbeInfo( COMPONENT_DATA,  DBFDBE_LOCKOFFSET, 0xFFFFFFFF )
   DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET, 0xFFFFFFFF )
   DbeSetDefault( "DBFNTX" )

RETURN

PROCEDURE Main
   local cFormat := "999,999,999,999,999"
   local aStru   := {{"Test","C",1000,0}}
   local nDauer
   local x, cDB

   set date german
   set century on
   set alternate to Protokoll.txt
   set alternate on

   nDauer := seconds()

   for x := 1 to 2
       do case
          case x = 1
               cDB := "TestDB4G"
               ? "Angefordert mit 0xFFFFFFFF"
               DbeInfo( COMPONENT_DATA,  DBFDBE_LOCKOFFSET, 0xFFFFFFFF )
               DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET, 0xFFFFFFFF )
          case x = 2
               cDB := "TestDB2G"
               ? "Angefordert mit 0x7FFFFFFF"
               DbeInfo( COMPONENT_DATA,  DBFDBE_LOCKOFFSET, 0x7FFFFFFF )
               DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET, 0x7FFFFFFF )
       end
       ?
      ? "Erzeuge",cDB,"    DBF:", DbeInfo( COMPONENT_DATA,  DBFDBE_LOCKOFFSET ),;
                      "    NTX:", DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET )
      ?
      dbcreate( cDB, aStru )
      use (cDB) NEW
      if neterr()
         ? "NetErr() meldet Fehler bei ",cDB
         inkey(10)
         quit
      endif
      if ! flock()
         ? "flock() fehlgeschlagen ",cDB
         inkey(10)
         quit
      endif
      ?
      ? time()
      ?
      ? "Test DBF    ",cDB, "      ",alias(), "   Select: ", select()
      ?
      ? "Feldanzahl: ",transform(fcount(),cFormat)
      ? "Header():   ",transform(header(),cFormat)
      ? "RecSize():  ",transform(RecSize(),cFormat)
      cls
      @ 1,1 say "Test Start "+time()
      @ 1+x,1 say cDB
      do while NewRecord()
         replace field->test with transform(recno(),cFormat)
         @ 1+x,15 say transform(lastrec(),cFormat)
      enddo
      ?
      ? "Lastrec():  ",transform(lastrec(),cFormat)
      ? "DbfFileSize:",transform(DbfFileSize(),cFormat)
      ? "fSize():    ",transform( FSize(cDB) ,cFormat)
      ?
   next
   nDauer := seconds() - nDauer
   ? "Programm beendet. Dauer: ",nDauer,"Sekunden"
   ? time()
   set alternate to
   inkey(0)
RETURN
*--------------------------------------------------------------------------------
FUNCTION DbfFileSize()
RETURN ( (RecSize() * LastRec()) + Header() + 1 )
*--------------------------------------------------------------------------------
Function BeschreibeFehler(oError)
   ? " - oError:args         ", oError:args
   ? " - oError:description  ", oError:description
   ? " - oError:genCode      ", oError:genCode
   ? " - oError:subCode      ", oError:subCode
   ? " - oError:subSystem    ", oError:subSystem
   ? " - oError:OsCode       ", oError:OsCode, " => ",DosErrorMessage(oError:OsCode)
return nil
*--------------------------------------------------------------------------------
Function ntrim(nWert)
return alltrim(str(nWert))
*--------------------------------------------------------------------------------
Function NewRecord()
   local bSaveError, oError, IsOK := .t.
   bSaveError := ErrorBlock()
   ErrorBlock( {|e| Break(e)} )
   BEGIN SEQUENCE
      dbAppend()
      if neterr()
         ? "NetErr() meldet Fehler bei dbAppend *** maximale Dateigröße erreicht ? "
         IsOK := .f.
      endif
   RECOVER USING oError
      ErrorBlock( bSaveError )
      IsOK := .f.
      ? "Fehler bei DBAppend(), LastRec()=",lastrec()
      BeschreibeFehler(oError)
      ? "Programm beendet nach Append-Fehler"  // Besser Append beendet nach ...
   END SEQUENCE
   ErrorBlock( bSaveError )
return IsOK
hier kommt nun das Ergebnisprotokoll:

Code: Alles auswählen


Angefordert mit 0xFFFFFFFF

Erzeuge TestDB4G     DBF:         -1     NTX:         -1


11:56:27

Test DBF     TestDB4G        TESTDB4G    Select:           1

Feldanzahl:                    1
Header():                     66
RecSize():                 1.001
Fehler bei DBAppend(), LastRec()=         2145339
 - oError:args          {}
 - oError:description   D
 - oError:genCode             8999
 - oError:subCode                0
 - oError:subSystem     BASE
 - oError:OsCode                 0  =>  Der Vorgang wurde erfolgreich beendet.
Programm beendet nach Append-Fehler

Lastrec():             2.145.339
DbfFileSize:       2.147.484.406

Angefordert mit 0x7FFFFFFF

Erzeuge TestDB2G     DBF: 2147483647     NTX: 2147483647


11:57:34

Test DBF     TestDB2G        TESTDB2G    Select:           2

Feldanzahl:                    1
Header():                     66
RecSize():                 1.001
Fehler bei DBAppend(), LastRec()=         2145339
 - oError:args          {}
 - oError:description   
 - oError:genCode             8999
 - oError:subCode                0
 - oError:subSystem     BASE
 - oError:OsCode                 0  =>  Der Vorgang wurde erfolgreich beendet.
Programm beendet nach Append-Fehler
Lastrec():             2.145.339
DbfFileSize:       2.147.484.406
Programm beendet. Dauer:         133,28 Sekunden
11:58:41
Beide erstellten Dateien sind genau gleich groß !

Code: Alles auswählen

Lastrec():             2.145.339
DbfFileSize:       2.147.484.406
Lastrec():             2.145.339
DbfFileSize:       2.147.484.406
Mit der aktuellen Version sind Dateien über 2 GB nicht möglich, wobei die tatsächliche Größe
auf der Festplatte je nach Header- und Satzlänge etwas darunter liegt.

Ich hoffe, dass wir mit Arctica dann SQLite auch als lokale Datei nutzen können. :-D
Gruß
Hubert
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von UliTs »

brandelh hat geschrieben:...
Ich hoffe, dass wir mit Arctica dann SQLite auch als lokale Datei nutzen können. :-D
Datei? Ich vermute, Du meinst mit SQLite die SQL-Datenbank ;-) .
Und ich hoffe, dass man mit Arctica weiterhin den ADS nutzen kann. Sonst ist Arctica für mich sowieso nur für die Tonne 8) .
Aber bis Arctica rauskommt vergehen vermutlich ja noch Jahre ... :angel8:

Uli

Edit: Hubert, der Titel ist nicht besonders genau: Du meinst doch: "Maximale DBF Größe mit 1.90.355 bei Einsatz des DBFNTX-Treibers", oder?
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15696
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 66 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von brandelh »

Datei? Ich vermute, Du meinst mit SQLite die SQL-Datenbank ;-) .
die "Datenbank" ist in einer Datei (die von der SQLite-DLL verwaltet wird), die meinte ich ;-)

der FOXCDX Treiber wird kaum mehr packen und die ADS interessiert mich nicht :badgrin:
Gruß
Hubert
psp
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 250
Registriert: Do, 22. Okt 2009 13:42
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von psp »

da muss ich bei einem Kunden ganz schön aufpassen, der kommt sehr nah dran, wenn er nicht sogar schon drüber ist
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12906
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 45 Mal

Re: Maximale DBF Größe mit 1.90.355

Beitrag von AUGE_OHR »

brandelh hat geschrieben:... nun steht ab und zu in der Doku aber auch der für 4 GB oder 2,4 GB Wert ... gibt es da Unterschiede ?

Code: Alles auswählen

? "Angefordert mit 0xFFFFFFFF"
DbeInfo( COMPONENT_DATA,  DBFDBE_LOCKOFFSET, 0xFFFFFFFF )  // gibt das 4 GB Dateien ? 
DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET, 0xFFFFFFFF )
? "Angefordert mit 0x7FFFFFFF"
DbeInfo( COMPONENT_DATA,  DBFDBE_LOCKOFFSET, 0x7FFFFFFF )  // nötig für 2 GB Dateien
DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET, 0x7FFFFFFF )
...
Mit der aktuellen Version sind Dateien über 2 GB nicht möglich, wobei die tatsächliche Größe
auf der Festplatte je nach Header- und Satzlänge etwas darunter liegt.
das ist so IMHO nicht ganz richtig den hier werden 4GB und 2GB in einen Topf geworfen.

ich hatte ja bei Mircos Problem die Daten per 100.000 "zerlegt", also nun das ganze mit APPEND
GB2MAX.JPG
GB2MAX.JPG (24.4 KiB) 6338 mal betrachtet
ich fange bei 2.400.000 Records an ! die Datei Grösse seht ihr im Snapshot. bitte den Lockoffset beachten !
wenn ich nun weitere 100.000 APPENDen will passiert das
GB24MAX.JPG
GB24MAX.JPG (47.27 KiB) 6338 mal betrachtet
also ist bei
Header-Größe: 3394 Byte
Datensatzgröße: 877 Byte
Feldanzahl: 105
Datensatzanzahl: 100.000
ca. 2.450.000 Schluss !!!

0x80000000 ist ja 2147483648 * 1.024 = 2,199.023 GB mehr geht also nicht

so und wo kommen nun die 4 GB her ? kennt ihr noch NTXLOCK2.OBJ ?
Die Datei NTXLOCK2.OBJ erlaubt einen größeren Offset für die Satz-
sperrung bei Verwendung des DBFNTX RDDs. Der Standardoffset ist
1.000.000.000 + RECNO(). Falls Ihre DBF Datei größer als 1.000.000.000
Byte und Ihre Applikation in einer Netzwerkungebung läuft, benötigen Sie
diesen Treiber, um ein physikalisches Sperren der Datei zu verhindern.
Durch Einbinden dieses OBJs ändert sich der Offset auf 4GB-RECNO().
Dadurch kann eine DBF Datei eine maximale Größe von 2 GByte erreichen.
Applikationen, die diesen Sperrmechanismus benutzen, sind nicht mehr
kompatibel mit dem Standard DBFNTX RDD und sollten deshalb Daten nicht
gemeinsam nutzen.
der NTX Index Offset wir auf 4 GB ( statt 1.000.000) erhöht was dann eine Benutzung der DBF bis 2 GB erlaubt wo ein "sperren" noch möglich ist.
da aber Alaska seine eigne Philosophie über Index locking hat konnte man wohl den Overhead "auslagern" und so noch 200-300 MB raus-kitzeln.


p.s. bei Mirco liegen die "interessanten" Daten wenn < 600.000, also kein Problem die in einem Rutsch mit APPEND FROM xxx FOR zu übernehmen.
gruss by OHR
Jimmy
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von UliTs »

AUGE_OHR hat geschrieben:...
p.s. bei Mirco liegen die "interessanten" Daten wenn < 600.000, also kein Problem die in einem Rutsch mit APPEND FROM xxx FOR zu übernehmen.
Zu Mirco gibt es ein Extra Thema, und da sind die "interessanten" Daten jenseits der 2GB-Grenze :-)
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15696
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 66 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von brandelh »

Was ich meinte ist, dass aktuell der Wert 0x7FFFFFFF und 0xFFFFFFFF die gleichen Dateigrößen erzeugt.
Das beweißt mein Testprogramm !
Es ist mir bewußt, dass beide Werte natürlich nicht gleich sind, aber die Unterstützung von Dateien bis 4 GByte
ist bis zur 1.90.355 nicht vorhanden bzw. nicht freigeschaltet.

Unter Clipper hat die Datei NTXLOCK2.OBJ NIE einen Wert größer als 2 GB freigeschaltet.
Die zitierte Stelle in der Doku ist offensichtlich falsch, denn Clipper und Xbase++ haben keinen unsigned 32bit integer Datentyp (DWORD)
sondern nur LONG. 0x7FFFFFFF entspricht der höchsten möglichen Zahl und ist kompatibel zu Clippers NTXLOCK2.OBJ.
0xFFFFFFFF wird in einer LONG zu -1 und das wird wohl auch der Grund sein, warum Alaska keine größeren DBFs unterstützen kann.
Sie müssten erst einen DWORD Datentyp ermöglichen ;-)
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15696
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 66 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von brandelh »

UliTs hat geschrieben:
AUGE_OHR hat geschrieben:...
p.s. bei Mirco liegen die "interessanten" Daten wenn < 600.000, also kein Problem die in einem Rutsch mit APPEND FROM xxx FOR zu übernehmen.
Zu Mirco gibt es ein Extra Thema, und da sind die "interessanten" Daten jenseits der 2GB-Grenze :-)
Uli
Ich wollte dir gerade widersprechen und habe die Byte-Größe auf der Festplatte nachgesehen ...

2.147.483.647 - maximaler Wert einer LONG
2.299.293.696 - Dateigröße auf Festplatte ...

ob dort die interessanten Daten waren muss Mirco mal bei Gelegenheit raus lassen ;-)
Gruß
Hubert
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von UliTs »

brandelh hat geschrieben:...ob dort die interessanten Daten waren muss Mirco mal bei Gelegenheit raus lassen ;-)
Hat er doch, wo sollen sie denn sonst stehen ;-) . Im Prinzip habe ich das Problem gelöst :angel3: . Nächste Woche wissen wir mehr.
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15696
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 66 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von brandelh »

brandelh hat geschrieben:Was ich meinte ist, dass aktuell der Wert 0x7FFFFFFF und 0xFFFFFFFF die gleichen Dateigrößen erzeugt.
Das beweißt mein Testprogramm !
Die Infos die Jimmy da zitiert hat sind überigens blau hinterlegt ... also neu geändert. Ich habe mal in der alten Doku nachgesehen ...
1.82.294 hat geschrieben: * DBFDBE (DATA-Komponente)
...
Spezifikation für DBF-Dateien
Element Spezifikation
Dateigröße Ist limitiert auf den Offset für Satzsperren ... Der Standard ist 2 GB (2 * 10^9 Byte) => 2.000.000.000
...
DBFDBE_LOCKOFFSET
Mit dieser Konstante läßt sich der Offset für Satzsperren abfragen oder ändern. Der Offset ist auf 2 Gigabytes voreingestellt. Er ist einstellbar, um den konkurrierenden Betrieb von Xbase++ Anwendungen mit Clipper Anwendungen in einem heterogenen Netzwerk zu garantieren. Bei Clipper 5.01 beträgt der Offset 1 GigaByte und bei Clipper 5.2 beträgt er 2 GigaByte, wenn die Datei NTXLOCK2.OBJ gelinkt wurde. Das Ändern des Offsets für Satzsperren sollte nur bei genauer Kenntnis des Sperrmechanismus' für Datensätze vorgenommen werden. Beispiel:

DbeInfo( COMPONENT_DATA, DBFDBE_LOCKOFFSET, 2*10^9 )

In dieser Zeile wird der Offset für Satzsperren bei der DATA-Komponente der Compound-DBE DBFNTX auf 2 Gigabyte gesetzt.
Achtung: Falls die DBFDBE als DATA-Komponente in einer Compound-DBE eingesetzt wird, muß die Änderung des Offsets auch für die ORDER-Komponente durchgeführt werden. Zum Beispiel muß bei der Compound-DBE DBFNTX sowohl die DBFDBE als auch die NTXDBE den gleichen Offset für Satzsperren haben. Bei der NTXDBE wird der Offset durch die Konstante NTXDBE_LOCKOFFSET eingestellt.
In der 1.90.331 hat man die Infos zu den Grundwerten verbessert ...
1.90.331 hat geschrieben: Spezifikation für DBF-Dateien
Element Spezifikation
Dateigröße Ist limitiert durch den Offset für Satzsperren Der Standard ist 1 GB (10^9 Byte) => 1.000.000.000
...
DBFDBE_LOCKOFFSET
Mit dieser Konstante läßt sich der Offset für Satzsperren abfragen oder ändern. Der Offset bestimmt die maximale Größe der DBF-Tabelle. Der voreingestellte Wert für den Offset für Satzsperren ist 1.000.000.000 oder ca. 1GB. Dies entspricht der maximalen Größe einer Clipper-kompatiblen DBF-Tabelle.
Mit Hilfe der Konstante DBFDBE_LOCKOFFSET kann die maximale Größe einer DBF-Dateien vergrößert werden. Um den Maximalwert von derzeit ca. 2,4GB einzustellen, muß ein Wert von 0x80000000 für DBFDBE_LOCKOFFSET gewählt werden. Wird die Einstellung DBFDBE_LOCKOFFSET auf einen Wert größer als den von Clipper unterstützten Maximalwert geändert, können die DBF-Dateien nicht mehr im konkurrierenden Betrieb mit Clipper verwendet werden. Da sich die verwendeten Offset für Satzsperren unterscheiden, ist ein wechselseitiger Ausschluß in diesem Fall nicht mehr gewährleistet.
In der 1.90.335 hat man die Infos zu den Grundwerten und auch die Erweiterung erklärt, allerdings sind nicht alle Passagen eindeutig bzw. identisch ... ;-)
1.90.335 hat geschrieben: Spezifikation für DBF-Dateien
Element Spezifikation
Dateigröße Ist limitiert durch den Offset für Satzsperren Der Standard ist 1 GB (10^9 Byte) ****
...
DBFDBE_LOCKOFFSET
Mit dieser Konstante läßt sich der Offset für Satzsperren abfragen oder ändern. Der Offset bestimmt die maximale Größe der DBF-Tabelle. Der voreingestellte Wert für den Offset für Satzsperren ist 1.000.000.000 oder ca. 1GB. Dies entspricht der maximalen Größe einer Clipper-kompatiblen DBF-Tabelle.
Mit Hilfe der Konstante DBFDBE_LOCKOFFSET kann die maximale Größe einer DBF-Dateien vergrößert werden. Um den Maximalwert von derzeit ca. 2,4GB einzustellen, muß ein Wert von 0x80000000 für DBFDBE_LOCKOFFSET gewählt werden. Wird die Einstellung DBFDBE_LOCKOFFSET auf einen Wert größer als den von Clipper unterstützten Maximalwert geändert, können die DBF-Dateien nicht mehr im konkurrierenden Betrieb mit Clipper verwendet werden. Da sich die verwendeten Offset für Satzsperren unterscheiden, ist ein wechselseitiger Ausschluß in diesem Fall nicht mehr gewährleistet.
nun wurde hier also schon mal der Hinweis auf die 2.000.000.000 mit NTXLOCK2.OBJ vergessen und ein 0x80000000 eingeführt, zusätzlich steht bei der NTXDBE der von Jimmy zitierte Hinweis
NTXDBE hat geschrieben: NTXDBE_LOCKOFFSET
Voreingestellt ist ein Offset von 1.000.000.000 (~1GB), welches kompatibel zu allen Clipper Versionen ist. Mit der Konstante NTXDBE_LOCKOFFSET kann das aktuelle Offset ermittelt oder ein neues bestimmt werden. Gültige Offsetwerte sind 0 bis 0xFFFFFFFF.
Um Index-Dateien, die größer als 1GB sind, verwalten zu können, gibt es für Clipper 5.2 und 5.3 die Objekt-Datei NTXLOCK2.OBJ. Diese Datei erhöht das Offset für NTX-Dateisperren von ~1GB auf 0xFFFFFFFF (~4GB). Um konkurrienden Betrieb mit derartigen Clipper Anwendungen zu gewährleisten, muß das Offset für implizite NTX-Dateisperren wie folgt angepasst werden:
DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET, 0xFFFFFFFF )
der auf jeden Fall falsch ist, Clipper hat 2.000.000.000 eingestellt und nicht 0xFFFFFFFF !

Wieso ich auf 0x7FFFFFFF komme weiß ich jetzt gar nicht, spielt aber auch keine wirkliche Rolle, solange alle Programme die auf eine DBF zugreifen den gleichen Wert haben.
Nun bleibt zu prüfen (mit kleinerer Satzlänge) ob 0xFFFFFFFF, 0x8FFFFFFF oder 0x7FFFFFFF eine Auswirkung auf die Dateigröße haben.

Zunächst noch der Beweis, dass 1.000.000.000 Standard ist ...

Code: Alles auswählen

#include "XBP.CH"
#include "DMLB.CH"
#include "DBFDBE.CH"
#include "ntxdbe.ch"
#include "Error.ch"

PROCEDURE Main
   set alternate to test.txt
   set alternate on
   ? DbeInfo( COMPONENT_DATA,  DBFDBE_LOCKOFFSET )
   ? DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET )
   inkey(10)
RETURN
gibt genau das aus
Standard bei Xbase++ und Clipper ist gleich ! hat geschrieben: 1000000000
1000000000
der Rest folgt ... ;-)
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15696
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 66 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von brandelh »

UliTs hat geschrieben:Im Prinzip habe ich das Problem gelöst :angel3: . Nächste Woche wissen wir mehr.
Uli
schön dass du das weißt, bevor Mirco die Daten geprüft hat ;-)
Gruß
Hubert
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von UliTs »

brandelh hat geschrieben:schön dass du das weißt, bevor Mirco die Daten geprüft hat ;-)
Du sprichst in Rätseln :roll: :?:
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15696
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 66 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von brandelh »

brandelh hat geschrieben:Ich wollte dir gerade widersprechen und habe die Byte-Größe auf der Festplatte nachgesehen ...
2.147.483.647 - maximaler Wert einer LONG
2.299.293.696 - Dateigröße auf Festplatte ... ???
Ich habe mit folgendem Programm die maximale DBF Größe mit der 1.90.355 getestet.
Exclusive und ohne Index dürfte der SHARE Wert keine Rolle spielen.
Die Satzlänge habe ich auf 18 begrenzt, damit die Grenze mit kleinen Blocks geprüft wird, wobei die Festplatte ja 512 Byte als Blockgröße nutzt.

Quellcode:

Code: Alles auswählen

#include "XBP.CH"
#include "DMLB.CH"
#include "DBFDBE.CH"
#include "ntxdbe.ch"
#include "Error.ch"

PROCEDURE DbeSys()
   IF !DbeLoad( "DBFDBE", .T. )
      ALERT( MSG_DBFDBE_NOT_LOADED, { "OK" } )
   ENDIF
   IF !DbeLoad( "NTXDBE", .T. )
      ALERT( MSG_DBFDBE_NOT_LOADED, { "OK" } )
   ENDIF
   IF !DbeBuild( "DBFNTX", "DBFDBE", "NTXDBE" )
      ALERT( MSG_DBFNTX_NOT_CREATED, { "OK" } )
   ENDIF
   DbeInfo( COMPONENT_DATA,  DBFDBE_LOCKOFFSET, 0xFFFFFFFF )
   DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET, 0xFFFFFFFF )
   DbeSetDefault( "DBFNTX" )
RETURN

PROCEDURE Main
   local cDBF, nWahl
   set exclusive on
   set alternate to test.txt
   set alternate on

   nWahl := 4

   do case
      case nWahl = 1
         cDBF := "Test_7F_exlusive.DBF"
         ? "Datei mit 0x7FFFFFFF - wo ich nur diesen Wert her habe ? "
         DbeInfo( COMPONENT_DATA,  DBFDBE_LOCKOFFSET, 0x7FFFFFFF )
         DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET, 0x7FFFFFFF )
      case nWahl = 2
         cDBF := "Test_8F_exlusive.DBF"
         ? "Datei mit 0x8FFFFFFF - Empfehlung von Alaska ? "
         DbeInfo( COMPONENT_DATA,  DBFDBE_LOCKOFFSET, 0x8FFFFFFF )
         DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET, 0x8FFFFFFF )
      case nWahl = 3
         cDBF := "Test_FF_exlusive.DBF"
         ? "Datei mit 0xFFFFFFFF - mehr geht nicht"
         DbeInfo( COMPONENT_DATA,  DBFDBE_LOCKOFFSET, 0xFFFFFFFF )
         DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET, 0xFFFFFFFF )
      case nWahl = 4
         cDBF := "Test_FF_voreingestellt.DBF"
         ? "Datei mit 0xFFFFFFFF - in DbeSys() eingestellt"

   end


   dbcreate( cDBF ,{{"SATZNR","N",18,0}} )
   use (cDBF)

   cls
   @ 1,1 say cDBF
   @ 2,1 say "Recno()"

   do while .t.
      append blank
      replace SATZNR with recno()
      if int(recno()/1000) = recno()/1000
         @ 2,15 say recno() picture "999,999,999,999"
      endif
   enddo
   inkey(10)
RETURN
hier ist die DIR *.DBF Anzeige - ich kann nicht nachvollziehen, wieso Mircos Datei größer war, meine sind alle gleich groß:

Code: Alles auswählen


D:\TEST\TestMaxSizeDBF>
dir *.dbf
...
23.02.2012  11:52     2.147.483.674 Test_7F_exlusive.DBF
23.02.2012  12:44     2.147.483.674 Test_8F_exlusive.DBF
23.02.2012  13:56     2.147.483.674 Test_FF_exlusive.DBF
23.02.2012  14:52     2.147.483.674 Test_FF_voreingestellt.DBF
               4 Datei(en)  8.589.934.696 Bytes
D:\TEST\TestMaxSizeDBF>
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15696
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 66 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von brandelh »

Hier noch die Fehlermeldungen der XppError.LOGs, alle gleich ...

Code: Alles auswählen

------------------------------------------------------------------------------
FEHLERPROTOKOLL von "D:\TEST\TestMaxSizeDBF\TEST.EXE" Datum: 23.02.2012 14:52:34

Xbase++ Version     : Xbase++ (R) Version 1.90.355
Betriebssystem      : Windows XP 05.01 Build 02600 Service Pack 3
------------------------------------------------------------------------------
oError:args         :
oError:canDefault   : J
oError:canRetry     : J
oError:canSubstitute: N
oError:cargo        : NIL
oError:description  : Interne Datenstrukturen besch„digt
oError:filename     : 
oError:genCode      :         41
oError:operation    : DbAppend
oError:osCode       :          0
oError:severity     :          2
oError:subCode      :          5
oError:subSystem    : BASE
oError:thread       :          1
oError:tries        :          1
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von MAIN(61)
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12906
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 45 Mal

Re: Maximale DBF Größe mit 1.90.355

Beitrag von AUGE_OHR »

hi,

ich habe doch auf den Lockoffset verwiesen den ich verwendet habe 2147483648 was auch die snapshots zeigen.
gebt den doch mal bei Windows CALC.EXE ein, als Dezimalwert, und schaltet dann auf HEX um -> 0x80000000
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12906
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 45 Mal

Re: Maximale DBF Größe mit 1.90.355

Beitrag von AUGE_OHR »

UliTs hat geschrieben:
AUGE_OHR hat geschrieben:...
p.s. bei Mirco liegen die "interessanten" Daten wenn < 600.000, also kein Problem die in einem Rutsch mit APPEND FROM xxx FOR zu übernehmen.
Zu Mirco gibt es ein Extra Thema, und da sind die "interessanten" Daten jenseits der 2GB-Grenze :-)
Uli
das sehe ich nicht so wenn ich mir die Daten "ansehe"
Und nur der Bereich 336147-504257 brauch / sollte / muss aus der Datei raus, da es sich hierbei um die Auftragspositionen der Aufträge handelt, die fälschlicherweise generiert wurden und nicht benötigt sind.
also

Code: Alles auswählen

APAUFNR < 336147-1 .OR. APAUFNR > 504257 .AND. APAUFNR <> 0
das "Problem" ist aber das die höchste APAUFNR, die noch ok ist, bei 489948 liegt d.h. es fehlen mindestens 14309 Aufträge "oberhalb".
bis zur APAUFNR 336147-1 sind es aber nur 567.930 Records ( inclusive delete )
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12906
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 45 Mal

Re: Maximale DBF Größe mit 1.90.355

Beitrag von AUGE_OHR »

brandelh hat geschrieben:Ich wollte dir gerade widersprechen und habe die Byte-Größe auf der Festplatte nachgesehen ...
2.147.483.647 - maximaler Wert einer LONG
müsste man den LONG Wert nicht noch mit * 1.024 berechnen ?
brandelh hat geschrieben:2.299.293.696 - Dateigröße auf Festplatte ...
was immer noch grösser ist als mein 2.147.483.648 * 1.024 = 2,199.023 GB

wie es Mirco also überhaupt geschafft hat ein APPEND mit Xbase++ über diese Grenze zu erzeugen ist mir schleierhaft wie mir mein Demo zeigt.

p.s. wir können die Frage ja auch Steffen morgen Fr. im Chat mal stellen ...
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15696
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 66 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von brandelh »

AUGE_OHR hat geschrieben:
brandelh hat geschrieben:2.147.483.647 - maximaler Wert einer LONG
müsste man den LONG Wert nicht noch mit * 1.024 berechnen ?
Dieser Wert entspricht genau 0x7FFFFFFF also 2 * 1024 (KB) * 1024 (MB) * 1024 (GB).
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15696
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 66 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von brandelh »

Nach erneuter Durchsicht der Doku steht dort nichts mehr von 0x7FFFFFFF und auch kein 0x8FFFFFFF.
Die 2,4 GB maximale Größe wären mit 0x80000000 zu erreichen. Mein Testprogramm läuft ;-)

und kommt zum gleichen Ergebnis wie oben !

Alaska hat übrigens geantwortet, dass die Clipper NTXLOCK2.OBJ tatsächlich auf "etwa 4GB" gesperrt hätte ...
ich habe nie Clipper und Xbase++ konkurierend genutzt, kann das also weder bestätigen noch widerlegen.

Aber ich habe ja noch Clipper auf der Platte und dort gibt es die Datei 52EGER.TXT die es genau erklärt:

ohne NTXLOCK2.OBJ: ein Byte auf 1.000.000.000 + recno() wird gesperrt.
mit NTXLOCK2.OBJ: ein Byte auf 4 GB - recno() wird gesperrt. Hoffen wir, dass sie 0xFFFFFFFF meinten ....
Gruß
Hubert
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9361
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 101 Mal
Danksagung erhalten: 361 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von Tom »

Ist das Thema eigentlich beim Chat mit Steffen angesprochen worden?
Herzlich,
Tom
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von UliTs »

Hallo Tom,

ja. Steffen meinte, Mirco solle sich an den technischen Support wenden.
Ich denke, Mirco hat dies nicht gemacht. War auch unnötig, da ich wohl alle korrekten Datensätze retten konnte :-) :angel3: .

Ich glaube, die zu große Tabelle hatte sowieso nichts mit xBase++ zutun, sondern ist stattdessen durch eine Fehlbedienung von einem Clipperprogramm entstanden.

Uli

P.S. wieso fragst Du?
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9361
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 101 Mal
Danksagung erhalten: 361 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von Tom »

Ich hatte das Ergebnis dieser Diskussion hier so verstanden, dass sich die Dateigröße nicht über 2 GB hinweg setzen lässt, was fatal wäre. Dahin ging meine Frage.
Herzlich,
Tom
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15696
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 66 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von brandelh »

Ich habe es mit allen Einstellungen und 1.90.331 und 1.90.355 getestet, meine waren immer einige Byte unter der 2 GB Grenze und das Programm starb weg.
Gruß
Hubert
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von UliTs »

Hubert,
Hast du es denn auch mit Append from versucht?
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15696
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 66 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Maximale DBF Größe mit 1.90.355

Beitrag von brandelh »

nein, ich baue im Beispielprogramm die DBF selbst auf, so wie ich es normalerweise brauche.
Gruß
Hubert
Antworten