>> Is this index recovery something you want to happen all the time? How
>> often are you seeing file corruption?
>
>Not just index recovery - general purpose indexing routine. And it has
>to be fullproof enough to work even if the table's indexes are totally
>corrupt. It will make new ones. It worked that way last five years, I'm
>just writing a VFP version.
>
>As for the file corruption, you'd be surprised. It happens where you
>don't expected. Many users never RTFM and they simply power off the
>machine anytime, and there's no way of guessing who's the one to do it.
>OTOH, my company specialized in software for agriculture, and we have
>installations in many forsaken villages (*) where the electricity may
>vary :). The existing versions of the routine have always done the job
>so far and I really have no problems, except with some legacy software
>which we kind of maintain... and didn't add this.
>
>(*) A footnote question: are there any villages in the USA (except
>Greenwich Village)? I've seen hundreds of north American movies, and I
>have literally _never_ heard of any place smaller than "our little
>town", even with population below 1K.
>
>> If this is something that will only run, say, nightly or even weekly, then
>> we can assume that it is going to be a primarily administrative task. That
>> being the case, we should be able to get exclusive access to the
>> DBC...correct? (I certainly hope so.)
>
>Yes... weekly or in case of damaged indexes/tables. It should simply
>skip the things it can't open exclusively (which has proven to be good
>strategy - once an index on a small table gets rotten, you open a form
>using the really big tables on the other machine, and then index on the
>first one - gets done real quick when it skips the long ones).
>
>> In this case, if the indices were maintained up until the time of the
>> corruption, then data integrity (PK) should be OK. At this point, if you
>> wipe out the index in question and the indices on any children and the open
>> then corresponding tables using an error handler to capture missing cdx
>> errors, shouldn't you be able to rebuild the indices without having to do
>> any low-level manipulation?
>
>The routine should run ok, no matter if anything is wrong or not.
>"Rebuilding the indices" is out of question if the .cdx files are
>damaged or missing, and I've always covered that case too. The problem
>arose with the .dbc - in case of a missing .cdx, it complains of missing
>PK, asks for a Vali Data, refuses to open the table (with and w/o dbc
>open) and misbehaves all the way.
>
>BTW, I've solved it and it works now (well, it worked in one version,
>it will work again) - involves Using the .dbc and a bit of messing with
>the .property memo field (before indexing I tell it "you have no PK"
>then I index, then I say "here's your PK"), and the RI doesn't complain
>either, since I'm not touching any of the records (no deletions,
>inserting etc) so it won't get triggered.
>
>LL manipulation is a must - if you want to open a table with a damaged
>..cdx, it won't open, unless you erase the .cdx; then, you try to open it
>and it asks for the removal of the .cdx reference. This dialog is
>something I must not allow to appear in an administrative routine -
>indexing was always a hands-off job, so I do use low-level writing to
>clear the has-a-cdx bit from the 28th byte of the table's header.
>
>The idea you gave me as to try to trigger the indexing routine from an
>error routine came to me quite lately (couple of weeks ago), and imagine
>- the first version of the indexer was written in 1989, and the
>open_it() function exists ever since. And it has an error routine of its
>own. Took me eight years to put those two together :)

Every sort of village or town exists in the USA, with populations approaching zero. A crossroads with a few houses and a gas station may be called a town. In remote western regions it's not unusual for towns of a few dozen people to have post offices, courthouses, or schools, generally serving a large, thinly populated area.

However realistic Hollywood movies may or may not be, a Hollywood producer or scriptwriter is unlikely to know much more about life in remote American towns than he does about life in, say, Yugoslavia. I have seen caricatures of such places in a few movies. I don't know if Hollywood has ever made a movie about life in Yugoslavia, but if they ever do, I suppose we'll all assume that what we see in it is how it really is.