Subject Re: Repair a corrupted DBT file From Tim Ward <tim@goldengrovenurserydotcodotuk> Date Sat, 27 Mar 2021 15:49:24 +0000 Newsgroups dbase.getting-started Attachment(s) HexCapture.PNG > Before we go any further, make sure you are working on copies of the > .dbf and .dbt file.  Use Windows or DOS, not dBASE, to copy the two files. Already taken care of. > The value used for a specific .dbt file is stored in > bit 21 i.e 0x15 (counting from 0 for the first bit) of the header. > Multiply this value by 128 to get the blocksize. The corrupted file seems to have the header missing as it starts with a block of info straight away. (if I look at a good file I can see bit 21) > I assume you have a hex editor (I use XVI32) which you used to change > the 4D0A in the .dbf file header to 430A.  This changes the field type > from M (memo) to C (character). > If you browse the .dbf file you should see a numeric value in the field. > Depending on how long your individual memos are they should vary between > 1 and perhaps twice the number of records in your .dbf file. They need > not necessarily be in order. Done and yes I get the numeric value pointing at the block for that record. I manually worked out that the block size is 512 and ran through the table extracting each block and matching for each record in the main table. I think this has got the right matches. Phew. I couldn't get it to work exactly as your program so I just read 512 bits from the start of the block but that gives me loads of extra characters. Attached is a screen shot of the start of the dbt file in XVI32. Is there something in each block that says how long the data is so I don't get all the extra characters. Bit 0 and 1 are always FF, and 2 is always 08. 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