2,3 GB große Clipper DBF Datei

[Mirco]

Hallo Leute,

ich hoffe bei euch ist alles ok .

Ich habe folgendes Problem:

Ein Kunde hat einen falschen Menüpunkt aufgerufen (bei einer Datenübertragung zwischen 2 Mandanten) und es wurde nicht nur ein paar Aufträge von einem Mandanten zum anderen überspielt, sondern alle ab 2007 (gute 160.000 Aufträge):D. Das hat die Auftragspositionsdatei wohl mehr als gesprengt (wenn man überlegt, das 10-100 Positionen pro Auftrag normal sind). Die Datei ist ~2,3 GB groß und ich finde keine Möglichkeit, die Sätze zu löschen. DBU macht gefühlt gar nichts und Database Architect gibt eine Fehlermeldung:

---------------------------
Error:
---------------------------
BrowseTable: Error 7016: Corrupt table. Make sure you are not attempting to open a DBF with an ADT table type or vice versa..

DatabaseName:
TableName: AUPOS.DBF
---------------------------

Packen im DBU führt zur sofortigen kompletten Leerung der DB. Export in SDF gibt kurz vorm Ende eine Fehlermeldung maximale Dateigröße erreicht.

Die Anwendung (Clipper) läuft allerdings anscheinend noch problemlos. Allerdings kann die Datei nicht mehr reindiziert werden, etc.


Habt ihr eine Möglichkeit, wie ich das wieder grade biegen kann? Neben den Auftragspositionen der 160.000 falschen Aufträge sind natürlich auch die Positionen der wichtigen Aufträge vorhanden, die dürfen ja nicht verloren gehen.

Vielen Dank und Gruß
Mirco

[Koverhage]

Und mit DBEditor (Xbase++ Anwendung ) ?

[Mirco]

Wo bekommt man ihn her ?

[brandelh]

Hi,

falls die Datei nicht wirklich defekt ist, musst du auf jeden Fall diese Zeilen setzen um den default Sperroffset zu erhöhen.

Code: Alles auswählen

#include "DBFDBE.CH"
#include "NTXDBE.CH"

*   DbeInfo( COMPONENT_DATA,  DBFDBE_LOCKOFFSET, 0xFFFFFFFF )  // 4GB Dateien
*   DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET, 0xFFFFFFFF )

DbeInfo( COMPONENT_DATA,  DBFDBE_LOCKOFFSET, 0x7FFFFFFF )  // 2GB Dateien
DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET, 0x7FFFFFFF )

der Maximalwert unter Xbase++ wird nicht einheitlich angegeben.

Ansonsten hilft - falls die Daten wichtig sind - nur in einer korrekten Version die Länge des Headers und des Satzes zu bestimmen
und mit fopen() und fread() die Daten zeilenweise einzulesen und umzukopieren. Das kann allerdings dauern

[brandelh]

Wo bekommt man ihn her ?

wenn man nach DBEDITOR sucht, findet man einen Verweis auf Phils (gerettete) Seiten:

http://www.xbaseprogrammer.com/PhilIde.cgi
etwa in der Mitte ...

VORSICHT wenn der kontrollierende Indexbegriff geändert wird ! Das bekommt die Anzeige nicht mit und dann werden Sätze überschrieben.

[Mirco]

Verdammt...Also, mal kurz meine Gedankengänge:

Mit DBMax (http://www.ebertonline.de/dbmax/downloads.htm) kann ich die Datei öffnen. Die letzten paar (Hundert-)tausend Datensätze sind allerdings ziemlich vermurkst, Daten stehen in falschen Feldern etc. Allerdings (das werde ich gleich auch nochmal nachprüfen) kann die Software wohl noch auf die Daten zugreifen. Kann das sein? Problem ist halt, dass zwar ein Backup der Datei besteht (von vor dem "Unfall", also von letzter Woche), allerdings fehlen ja alle Aufträge bis heute.

Was würdet ihr empfehlen? Bin grad ratlos, wie ich vorgehen soll...

[Mirco]

Hi,
Ansonsten hilft - falls die Daten wichtig sind - nur in einer korrekten Version die Länge des Headers und des Satzes zu bestimmen
und mit fopen() und fread() die Daten zeilenweise einzulesen und umzukopieren. Das kann allerdings dauern

Hättest du da vielleicht mal einen Schnipsel für mich, wie das geht? Hab in Clipper bis jetzt kaum gearbeitet...

[brandelh]

Die Auträge nacherfassen ist am sichersten, ihr habt die doch noch per eMail oder Papier oder ?
Wer weiß schon welche Daten falsch überschrieben wurden.

[Koverhage]

wahrscheinlich alle > 2 GB also die neuesten

[UliTs]

Hallo Mirko,

komm heute Abend einfach beim User-Meeting in Leverkusen vorbei. Vielleicht bekommen wir es dann gemeinsam hin .

Uli

[Mirco]

Hm, das sind hunderte von Aufträgen, denke das dauert Tage...Habe grade den Kunden gebeten sich mal einen Auftrag anzuschauen, dessen Positionen in der Datei ziemlich wild dargstellt werden (die Infos der ersten X Felder stehen in einem Characterfeld, ist auch einer der "letzten" Aufträge). Er kann sich den Auftrag ganz normal anzeigen lassen. Da muss es doch eine Möglichkeit geben, das wieder grade zu biegen, oder?

[Koverhage]

Vielleicht mit Windbf32 ?

[Mirco]

Ja danke, versuche ich direkt mal aus.

Bin zumindest soweit, dass ich die Datei im Architekten öffnen kann (hatten noch so ne Art DBFRepair-Tool aufm Sever rumfliegen). Allerdings besteht halt weiterhin das Problem, dass die Felder der letzten Sätze alle verschoben sind.

Habe außerdem mit dem Kunden telefoniert, nacherfassen der Aufträge ist unmöglich, sind hunderte von Aufträgen, außerdem noch Aufträge die aus anderen Firmen übernommen wurden (ist ein spezieller Fall, da tauschen 3-4 Kunden von uns gegenseitig Aufträge etc aus). Also "muss" ich irgendwie schauen, dass ich die Datei wieder fit kriege .

[Friedhelm]

Hallo Mirco

Du solltest mal das Database Repair Utility von ADS probieren. Mit diesem Tool lassen sich defekte Datentabellen rekonstruieren.

Du findest das Utility unter http://devzone.advantagedatabase.com


mfg
Friedhelm

[Mirco]

Hab in der Devzone nichts gefunden, hast du vielleicht einen Link?

Also habe bis jetzt mehrere Tools ausprobiert, leider hat bis jetzt nichts geholfen...

Habe auch versucht eine kleine Clipper-Routine zu schreiben, die die besagte korrupte Datei durchgeht und die Daten in neue Dateien ausgibt (immer 800.000 Sätze und mit Datei->Feld := AlteDatei->Feld), aber der lief sehr schnell durch und in der neuen Datei steht auch nichts...

Über weitere Ideen bin ich sehr froh, ich habe euch auch einmal besagte Datei zur Verfügung gestellt (ist gepackt nur 33 MB groß . Falls ihr selber mal etwas ausprobieren wollt .

Ich benötige im Endeffekt alle Sätze, deren Auftragsnummer (APAUFNR) NICHT in den Bereich liegt: 336147-504257. Bedeutet also, alle Sätze in dem Bereich müssen / dürfen raus.

Vielen Dank!

[AUGE_OHR]

hi,

da hast du dir aber was schönes eingebrockt ...
warum arbeitest du mit so grossen DBF Datein ? sind das alles "aktuelle" Daten ?

aber egal, du hast jetzt das Problem ... also mal sehen ...
wie Huber schon sagte würde ich mit

Code: Alles auswählen

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" )

anfangen damit du die DBF öffnen kannst

Code: Alles auswählen

PROCEDURE MAIN
LOCAL aStructure
LOCAL nRec
LOCAL cFile
LOCAL i := 0

  CLS

  USE aupos.dbf EXCLUSIVE
  ? nRec := Reccount()   // negativer Wert
  ? nRec := Lastrec()     // 42........ Wert 
WAIT
  
  // ist der DBF Header noch ok ?
  aStructure := DbStruct()
  AEval( aStructure, {|a| QOut( a[DBS_NAME] )} )
WAIT

  if nRec > 0
     GOTO(nRec)
     // sehen ob noch was da ?
     AEval( aStructure, {|a| QOut( &(a[DBS_NAME]) )} )
WAIT
  endif

soweit so gut ... aber der FELD Inhalt des letzten Record ist wohl "kaputt" ...

du müsste ungefähr wissen "wo" es anfängt ... z.b. wo eine FELD ein bestimmten Inhalt hat oder so denn sonst gibt es nur dies

Code: Alles auswählen

GO TOP
// besser währe ein GOTO(nAnfang)
DO WHILE !EOF()
   i++
   cFile := "Part"+STRZERO(i,4)+".DBF"

   ? cFile, STR(RECNO())
   COPY TO &(cFile) NEXT 100000 VIA "DBFNTX"
   SKIP+1
ENDDO

damit solltest du "Part" weise die Daten retten können ... das kann dauern ...

p.s. ist doch immer wieder verwunderlich wie viel "Luft" in einer DBF beim komprimieren ist.

Nachtrag : fange bei

Code: Alles auswählen

GOTO( 1118202+(13*100000) )

an mit COPY TO ... da geht es mit

Code: Alles auswählen

IF EMPTY(FIELD->Apaufnr)

irgendwann los.
er wird bei den 100.000 noch durchkommen um dann endgültig beim nächsten Durchlauf bei 97.590 abzustürzen.

[Koverhage]

Ich denke die ganzen Repair Utilities schaden mehr als sie nützen.

Ich würde wie folgt an die Sache gehen.

Aupos bedeutet das es auch Aukopf gibt.
Aukopf durchgehen und die dazugehörigen Positionen in eine neue Tabelle schreiben.
Für die Sätze in der Aupos die bei der 2GB Grenze liegen und nicht gefunden werden
würde ich die aus der repos nehmen, denn fakturiert sind die ja wohl oder ?
Dies Programm zu erstellen ist ca. 1 Stunde Aufwand.
Alles andere macht meines Erachtens keinen Sinn.

[AUGE_OHR]

hi,

wie ich sagte : die DBF ist bis RECNO() -> 1118202+(13*100000) -> 2418202 OK
ein

Code: Alles auswählen

COPY TO &(cFile) NEXT 2418202 VIA "DBFNTX"

erstellt dir aber immer noch eine > 2GB Datei.

genau gesagt "müsste" bis FIELD->Apaufnr = 489948 alles ok sein ... die 49 ist wohl schon defekt.

p.s. binde doch eine Progressbar in den COPY TO Befehl ein denn das dauert ...
http://www.xbaseforum.de/viewtopic.php? ... 4&start=40

[Koverhage]

336147-504257.

werden nicht benötigt.

Jimmy,
klar die Sätze die Mirco nicht braucht sind in Ordnung. Deswegen nützt das alles nichts.

Das Problem ist: Die Daten ab ca. 2GB Höhe (war ja mal systembedingt) sind Schrott, da
sie nicht richtig geschrieben wurden. Das kann man mit Visual DBU sehr gut sehen, die
Sätze enthalten fast nur 0 Werte.

Dieses Problem könnte man nur vermeiden, wenn man eine eigene Fehlerkontrolle
einbaut (DBESYS), die prüft ob Felder ein Feld auch die gewünschten Daten enthält.
Beispiel: Replace Apaufnr with 123456
dbskip(0)
if Apaufnr = 123456
alles ok
sonst Fehlerbehandlung.

[brandelh]

HI,

da die DBF über die Höchstgrenze hinaus beschrieben wurde (mit Abbruch ?) ist es sehr wahrscheinlich,
dass die Infos im HEADER() der defekten Datei nicht mehr gültig sind. Daher der von mir empfohlende native Zugriff.

Grundsätzlich sind die "rohen Daten" ja leicht zu erkennen, wenn man z.b. mit einem HEX-Editor dran geht.
Zur Untersuchung bräuchte man einen Satz korrekte DBF ohne Inhalt und dann müsste man wie von KOverhage beschrieben
laden was drinn ist. Eventuell kann man dabei schon die "unnötigen" Daten filtern.

PS: ich halte es für bedenklich (Datenschutz, Auftraggeber ?) die Originaldatei hier öffentlich zur Verfügung zu stellen
Besser wäre es diese per PN an interessierte Mitglieder zu senden
Bitte stelle hier die LEERE DBF rein, die vom Satzaufbau her zur Defekten passt.

Dann versuche ich ein allgemein gültiges Programm zu bauen, das aus der defekten die Daten in die gesunde umlädt.
Das wäre dann - ohne die Originaldatei - etwas für die Wissensbasis.

PS: natürlich muss man aus der einen defekten wegen der 2 GB Grenze mehrere neue machen.

[Mirco]

Hallo Leute,
Vielen Dank für die Hilfe, ich bin gerade nicht im Büro, melde mich gleich gegen 13 Uhr mit den benötigten Infos!

Vielen Dank!

[AUGE_OHR]

PS: natürlich muss man aus der einen defekten wegen der 2 GB Grenze mehrere neue machen.

das ist ja das was ich mit den "Parts" oben vorgeschlagen habe.

Das kann man mit Visual DBU sehr gut sehen, die
Sätze enthalten fast nur 0 Werte.

ich gehe davon aus das du die DBESYS wie oben beschrieben auf 4GB modifiziert hast ?

ich sag es jetzt noch mal : alle Daten die man mit

Code: Alles auswählen

COPY TO &(cFile) NEXT 2418202 VIA "DBFNTX"

kopiert sind IMHO ok !!!

die RECNO() = 1118202 enthält EMPTY(FIELD->Apaufnr), deshalb hat er dort das erst mal gestoppt.
danach läuft er noch 14 x 100000 Sätze durch um dann im 15st abzustürzen.
in der 14th DBF sind zum Schluss bei FIELD->Apaufnr > 489948 +1 dann die Daten "kaputt".

[AUGE_OHR]

Dann versuche ich ein allgemein gültiges Programm zu bauen, das aus der defekten die Daten in die gesunde umlädt.
Das wäre dann - ohne die Originaldatei - etwas für die Wissensbasis.

hole dir mal den native Progressbar aus der Wissensbasis.
nimm das Demo CopyFile.PRG und setzte es auf die "defekte" DBF an.

oError:args :
-> VALTYPE: N VALUE: 85
-> VALTYPE: N VALUE: *****.****
oError:canDefault : J
oError:canRetry : N
oError:canSubstitute: N
oError:cargo : NIL
oError:description : Länge des Datenbankfeldes wurde überschritten
oError:filename :
oError:genCode : 63
oError:operation : FIELDPUT
oError:osCode : 0
oError:severity : 2
oError:subCode : 8029
oError:subSystem : BASE
oError:thread : 1
oError:tries : 0
-------------------------------------------------------------------
CALLSTACK:
-------------------------------------------------------------------
Aufgerufen von DBEXPORTRECORD(322)
Aufgerufen von (B)DBEXPORT(286)
Aufgerufen von DBEXPORT(286)
Aufgerufen von _DBEXPORT(137)
Aufgerufen von MAIN(130)

das passiert wenn man die "kaputte" Stelle erreicht was man sich dann in der neuen DBF als letzten Datensatz ansehen kann.
allerdings sind wie ich schon sagte da schon eine Menge 0 drin, also mit WHILE FIELD->Apaufnr < 489948 +1 den COPY TO Befehl eingrenzen.

solange der DBF Header nicht "kaputt" ist kann man mit COPY TO den Rest "retten", dafür braucht man keine "Extra" Tools für Mircos Problem.

Nachtrag : diese DBESYS.PRG mit CopyFile.PRG verwenden

Code: Alles auswählen

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" )

[Tom]

Dieser Code (nicht auf Herz und Nieren getestet) sollte eine defekte Datei umkopieren, auch an fehlerhaften Datensätzen vorbei. Geöffnet sind die zu kopierende Datei (Alias in "cAlias") und eine Strukturkopie mit dem Alias "neu", beide exclusiv:

Code: Alles auswählen

bError := ErrorBlock({|e|Break(e)})
nRecNo := 0
DO WHILE !Eof()
  IF RecNo() = nRecNo
    DbSkip(1)
  ENDIF
  nRecNo := RecNo()
  BEGIN SEQUENCE // Laufzeitfehler werden ignoriert
  DbSelectArea('neu')
  APPEND BLANK
  FOR i := 1 TO nFCount
    x := (cAlias)->(FieldGet(i))
    FieldPut(i,x)
  NEXT
  RECOVER USING oError
    i ++
    DbSelectArea(cAlias)
    DbSkip(1)
    LOOP
  END SEQUENCE
  DbSelectArea(cAlias)
  DbSkip(1)
ENDDO
ErrorBlock(bError)

[Mirco]

PS: ich halte es für bedenklich (Datenschutz, Auftraggeber ?) die Originaldatei hier öffentlich zur Verfügung zu stellen
Besser wäre es diese per PN an interessierte Mitglieder zu senden
Bitte stelle hier die LEERE DBF rein, die vom Satzaufbau her zur Defekten passt.

Ja, ich war auch am überlegen wg. Datenschutz, aufgrund der sehr mageren Infos in der Datei dachte ich allerdings, es wäre ok. Habe die Datei aber wieder entfernt .

Vielen dank euch allen, ich bin jetzt grade zu Hause / im "Büro" angekommen und werde mir eure Vorschläge jetzt gleich durchlesen.

Auf jeden Fall gibt es hier:

http://dl.dropbox.com/u/19398160/AUPOS.DBF

die gewünschte leere DBF-Datei.

Die Aufträge in dem oben genannten Bereich können / sollen ja im Endeffekt gelöscht werden. Das bedeutet von 160.000 Aufträgen die Positionen, da sollte doch die Enddatei wieder im "normalen" Bereich liegen, oder?

Wenn noch Fragen sind (ob technisch oder "inhaltlich"), einfach her damit. Vielen Dank für die Unterstützung!