Kevin,

Just to highlight the difference between re-building indices, and 
re-building tables/data...

Rebuilding indices, optimising them, even packing the table-data, should 
be quite straightforward - if the DATA is not corrupted.

But, if the DATA file is corrupted, analysing that load of cr*p could be 
extremely difficult. Briefly, it would mean that the repair program 
should note the structure of each record, and then the size and binary 
structure of each field. Then, it'll have to read through all the 
physical disk blocks/sectors/clusters of the data, and check the header 
bytes, and that the structure of data-bytes on each sector matches the 
record layout. Sooner or later, the program will, likely, find blocks 
which do not match, and it must then try to work put the structure of 
the data it sees, and check if it is a partial match with the table 
structure, and check if it can merge such partial records with other 
corresponding part-records, etc.

This could be extremely challenging!

Ironically, if a table has many, different field types, that structure 
might be a little easier than a simple structure. For example, if a 
simple table layout had just 5 alphanumeric fields of 5 bytes each, then 
(apart from headers in each block) the it might be almost impossible to 
identify corrupted blocks, and the individual fields in corrupted blocks.

Regarding CS itself, in some versions I checked a long time ago, it was 
unable to build optimised indices and data even on NON-corrupted data 
tables!

   - Mike


On 29/11/2020 20:35, Kevin Zawicki wrote:
> Automated repair - agree
> 
> 
> But automated table rebuilds and reindexing and packing was nice.
> 
> Also, I have a system with 350+ tables organized over many grouped folders.
> Looking for a way to check all of them and see what needs rebuilding.
> 
> If user reports error I can usually narrow it down to tables being touched,
> but then have to check many of them to find the problem.
> 
> 
> "Steven Green" <greens@diamondsg.com> wrote:
>> haven't really touched Chimney Sweep much, for a few years.. didn't know
> it
>> doesn't work on Win10.. just another brick in the wall :-)
>>
>> I'm generically against relying on automated repair processes, cuz if the
> 
>> table fails it takes a human eye to see it.. and no matter how you deal
> with
>> it, step one is to get every paradox login closed.. sometimes easier said
> 
>> than done
>>
>> --
>>
>> Steven Green
>> Myrtle Beach, South Carolina, USA
>>
>> http://www.OasisTradingPost.com
>>
>> Collectibles and Memorabilia
>> Vintage Lego Sets and Parts
>> - and Paradox support, too
>> "Kevin Zawicki"  wrote in message
>> news:5fc2f8ae$1@pnews.thedbcommunity.com...
>>
>>
>>
>>
>> Move to Windows 10, lost use of Chimney Sweep.
>>
>> (I know I can run a VM, not ready to do that yet.)
>>
>>
>> Looking at building my own using interactive rebuild, compact, etc.
>>
>>
>> reIndexAll ( ) Logical
>> Is the same a restructure (mostly)?
>>
>> Anyone have an automated rebuild routine?
>> Not looking to run blind, but mimic Chimney Sweep.
>>
>>
>> Also, the table rebuild function on my win 7 machine would work, but leave
>> the completed message for the table open and unclosable. I would move to
>> side and do another, etc, they would pile up on the side.
>>
>>
>> Not seeing that in windows 10.
>>
>>
>>
>>
>>
>>
>>
>