thanks.. been there, did all of those things.. assumed I'd find the 
offending record and delete it.. then it started moving :-)

it's gotta be a bad pointer in one of the indexes, but with 24 to check 
manually, it's not worth the effort, for now.. that's the biggest issue with 
these old apps.. all the eff-ing indexes.. it was so cutting-edge, so 
simple.. make an index for everything.. 20 years later, you have 400 files 
open at once, hundreds of thousands of records, and everyone beating on all 
of it, all day long

--

Steven Green
Myrtle Beach, South Carolina, USA

http://www.OasisTradingPost.com

Collectibles and Memorabilia
Vintage Lego Sets and Parts
- and Paradox support, too
"Michael Kennedy"  wrote in message 
news:5bfb160e$1@pnews.thedbcommunity.com...

A few thoughts...

To me, 80,000 does not seem large, but 24 does  ;-)

How about copying the table structure only, and then "adding" all the
current data into the new structure, etc...

Or... How about splitting the current table into, say, three sub-tables,
with about 27,000 records each (well under that darn 32,768 limit!), and
then running Repair on each sub-table. If each sub-table is error-free,
that might suggest that the data in the individual records is not the
problem, but perhaps the "volume" of records, and you might have hit a
variation of that darn 32,768 issue among all those secondary indices.

Also, if you have ChimneySweep handy, maybe it's worth a shot? (However,
I did try/stress it (a lot!), some years ago, with no success!).

   - Mike


On 25/11/2018 14:29, Steven Green wrote:
> huge table.. 80,000 records, 24 sec indexes, a couple of memo fields.. no, 
> I didn't create this monster
>
> repair says record 28728 is out of sort order.. rebuild, still there.. 
> delete it, now the record BEFORE it is now out of sort order, not the 
> record AFTER it
>
> stranger still, there's seemingly nothing wrong with the record that stops 
> anything.. I can add it back to the table w/o an error, I can edit it and 
> leave the record w/o an error, so none of the lookup values is invalid
>
>
> -- 
>
> Steven Green
> Myrtle Beach, South Carolina, USA
>
> http://www.OasisTradingPost.com
>
> Collectibles and Memorabilia
> Vintage Lego Sets and Parts
> - and Paradox support, too