Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
end of file
- Thread starter linoletto
- Start date
The "End Of File" cannot be encountered in the physical middle of an actual DBF file.
BUT it might seem that way if you have an Index or Filter on which prevents any other records from being 'seen' below some point (which might be in the middle) when you attempt to move to the next record.
Or if you have an Index which 'organizes' the table so that the last physical table record 'appears' somewhere the middle of the display/search.
Good Luck,
JRB-Bldr
BUT it might seem that way if you have an Index or Filter on which prevents any other records from being 'seen' below some point (which might be in the middle) when you attempt to move to the next record.
Or if you have an Index which 'organizes' the table so that the last physical table record 'appears' somewhere the middle of the display/search.
Good Luck,
JRB-Bldr
- Thread starter
- #3
If I a see that buggy DBF file with a hex editor, the first byte of the rekord is the deletion mark (h20 if not deleted, h2A if deleted).Some records have h1A witch is ctrl+z (end of file) sign.
Normally it is at the end of file (last character of the file) where it is accured. The browse command shows this record as deleted, however it isn't.
Normally it is at the end of file (last character of the file) where it is accured. The browse command shows this record as deleted, however it isn't.
Olaf Doschke
Programmer
Hi linoletto,
very good info. This explains an EOF in the middle of data. I don't know though, how that happens. Of course the EOF mark is only correct as the last byte after the last record. Looks like appending or inserting doesn't first change the EOF mark to Space (h20) so you get an EOF in the middle of nowhere.
I don't know of a foxpro bug that does this. So what version of foxpro is used, are there other appllications using the same dbf? Are they perhaps setting the EOF? Is there some reason behind it, perhaps a reorganization of the dbf putting double, deleted, unwanted records to the end and truncating the file by poking a EOF mark? This may have been a technical trick used by dbase to "pack" a dbf, I doubt but it could be the reasoning behind setting a EOF mark.
What you can do of course is use low level functions and check for 1A where either a deletion mark 2A (*) should be or a 20 (space) for undeleted records. You can make use of Recsize() and Header() to traverse the dbf and find the first bytes of records and check them.
Bye, Olaf.
very good info. This explains an EOF in the middle of data. I don't know though, how that happens. Of course the EOF mark is only correct as the last byte after the last record. Looks like appending or inserting doesn't first change the EOF mark to Space (h20) so you get an EOF in the middle of nowhere.
I don't know of a foxpro bug that does this. So what version of foxpro is used, are there other appllications using the same dbf? Are they perhaps setting the EOF? Is there some reason behind it, perhaps a reorganization of the dbf putting double, deleted, unwanted records to the end and truncating the file by poking a EOF mark? This may have been a technical trick used by dbase to "pack" a dbf, I doubt but it could be the reasoning behind setting a EOF mark.
What you can do of course is use low level functions and check for 1A where either a deletion mark 2A (*) should be or a 20 (space) for undeleted records. You can make use of Recsize() and Header() to traverse the dbf and find the first bytes of records and check them.
Bye, Olaf.
- Thread starter
- #5
- Status
Similar threads
