Subject Re: Repair a corrupted DBT file From Mervyn Bick <invalid@invalid.invalid> Date Mon, 29 Mar 2021 09:17:10 +0200 Newsgroups dbase.getting-started On 2021/03/27 21:03, Tim Ward wrote: >> Bit 4 seems to be a bigger number if the text I need is more but I >> couldn't quite see the correlation. >> >> I can delete unnecessary data manually but it's be easier to automate it. >> >> thanks Tim > > Hi Mervyn > > I had another go at this and the bit value at position 4 was showing the > length of the 'real' data. It was just a bit muddled and hard to see > where the end was as extra data from other records had been appended to > various blocks as a result of the corruption I think. > > Anyway all recovered thanks to your code. Now on to implement a better > backup regime. Good to hear that you could sort the problem out. The length of the memo is actually held in 4 bytes.  If only 1 byte was used the memo couldn't be longer than 255 characters.  The length is held in small endian format in 4 bytes starting at byte4 (the 5th byte) of the memo block. The length is calculated by (the value in) byte4 + byte5*1x10 + byte6*0x100 +byte7*0x1000. If the .dbt table is saved in sectors previously unused on the disk the extra spaces will be filled with 0x00.  When a file is deleted Windows does not delete the actual data but simply returns the sector to the list of available sectors.  When the sector is reused new data is written but the old garage remains in the unused bytes in the sector. It is, therefore, essential for dBASE to know how many characters are in the memo. Because dBASE, for some reason, wrote a memo into the heading space at the top of the .dbt table information about the name of the associated .dbf file, the next block to use and the block size was destroyed.  The only way to get the block size was by inspection. Mervyn.