>>VFP 5.0a SP3
>>
>>Until today, I believed that an index could only be corrupted by exiting from a running program in a rude way (Ctrl-Alt-Del, pull the plug, etc.) but today I have corrupted one of two indexes in a CDX file.
>>
>>Because of some index corruption in the field, I wrote a program to test some code I had that is supposed to recycle records in a table. The test program rapidly adds 3000 records to a table by either adding a new record (INSERT INTO) or by recycling a record (REPLACE ... WITH ...) that has my lDeleted field set to .T.
>>
>>When I ran the test program, everything worked fine. My real world application, though, has many processes (exe’s) running the same code, and the table updates will regularly have to deal with contention issues. To simulate this, I ran 10 copies of the test program at the same time. At the end, one of the two indexes in the target table “MatchQue” was corrupted. Interestingly, the corrupted index was not the one that I was using to find records suitable for deletion, but rather, one that was not referenced in the test.
>>
>>What can I do to stop the index corruption my index?
>>
>>The test program calls GenMatchEvent() 3000 times - see below. On 80% of the cycles, the test program sets MatchQue.lDeteted to .T. to simulate the real world where the records get "deleted".
>>
>>Bob
>>

>>*////////////////////////////////////////////////////////////
>>function GenMatchEvent
>>LOCAL liRecno, lnOldSelect, lcOldOrder
>>
>>lnOldSelect	= select(0)
>>lcOldOrder	= order()
>>SELECT MatchQue
>>
>>liRecno = RecycleIflDeleted()  && Returns RecNo to Recycle,
>>                               && or –1 if no recyclable records
>>                               && are available
>>IF liRecno = -1
>>  INSERT into MatchQue (icallnum,cfleet,cvehicle,cMatchtype,tRefTime) ;
>>         values (tiID,tcFleet,tcID,tcType,ttRefTime)
>>ELSE
>>  BLANK
>>  REPLACE MatchQue.icallnum   with tiID   ,;
>>          MatchQue.cfleet     with tcFleet,;
>>          MatchQue.cvehicle   with tcID   ,;
>>          MatchQue.cMatchtype with tcType ,;
>>          MatchQue.tRefTime   with ttRefTime in "MatchQue"
>>  unlock record liRecno
>>ENDIF
>>
>>SELECT (lnOldSelect)     && Restore original
>>SET order to &lcOldOrder && Restore original
>>
>>
>>*////////////////////////////////////////////////////////////
>>function RecycleIflDeleted()
>>local lnReturnedRecNo, lnOldSelect, lcOldOrder, lnOldReprocess
>>
>>tcTableName = alias()
>>lnOldSelect	    = select(0)
>>lcOldOrder	    = order()
>>lnOldReprocess  = set("reprocess")
>>
>>select (tcTableName)
>>set order     to MyDeleted  && indexed on MatchQue.lDeleted
>>set reprocess to 1
>>
>>lnReturnedRecNo = -1  && Initialize as Recyclable (lDeleted = .t.)
>>                      && record not found
>>if seek(.t.)
>>  do while !eof() and lDeleted
>>    if rlock()
>>      if lDeleted                 && Didn't changed while getting
>>        lnReturnedRecNo = recno() && the lock so we will send back
>>        exit                      && it's record # for recycling.
>>      else
>>        unlock record recno()     && unlock JUST this one
>>      endif
>>    endif
>>  	 	
>>    skip
>>  enddo
>>endif
>>
>>select            (lnOldSelect)
>>set order      to &lcOldOrder
>>set reprocess  to lnOldReprocess
>>
>>return lnReturnedRecNo
>>

>There is an article on my web site about corruption that may give you some ideas.

Thanks Craig for taking a break from the T-Day preparations. Your article has a number of good ideas on defending against the rude exit. Have you come across any "corruption on the fly" before. My process can run for weeks (24 Hr 7 Days/Wk) then start getting lost. The fix is always a fresh index, and there is never any corruption in the index header. I've tracked it down to the recycle routine, and the trigger seems to be something that I have failed to protect against during periods of VERY high contention. I could see 6 or more processes going after the same record at the "same" time, (and then the same next record if they can't get a lock).

Bob