>>>I wrote something of the kind long ago, but it needs to know the table structure in advance, i.e. it's generated code, so it can do its thing even when table header is overwritten. It was up to date with table structures as of VFP6 or so - so it's not handling nulls, variable length types, blobs and autoincrement fields. Also not sure if it handled memos when blocksize was zero.
>>>Though I could have written those as well, never did because I didn't need to (was in the US at the time and the SMB2 bug wasn't invented yet).
>>
>>Tables are created in code using create table and customer specific columns are added using alter table from data dictionary.
>>Database heade (except record count) never gets corrupted so its repairing is not needed.
>>Code fixes fox2 y header / file size count mismatches and invalid pointer to fpt file block. This is sufficient, no other fixes are needed.
>
>Then you are just lucky. At the time I had to write this (including a FPT rebuilder), headers on both dbf and index files had found a way to be completely destroyed, overwritten by garbage. Caused by bad wiring, peaks and brownouts in the power grid (villages near the border were the worst), high heels getting snagged by coaxial cables, welding or Röntgen machines near the network cables or a workstation getting stuck by another process.
>
>So when writing these rebuilders, I had to assume that any part of the file may be in very bad shape.

In my case users are connected using LAN in office, no internet is used.
Network connection almost never breaks.