>I see only an deleted one that has somehow missed the garbage collection or concurrently action. The problem is there is some garbage collection on this file so I might not reproduce at all.
>:
Seems your error handler needs to show more information - seldom needed, but for some cases a real time saver or only hope. Depends a lot on budget...
Unless you can reproduce, Gremlins can never be excluded!

>
>The index itself seems unharmed, the error occured once 24hours ago and never again.
>
>What I' curious is that record 193 of 194 on EOF() in INSERT after a failed SEEK, deleted one?

unclear what exactly you meant. One recurring problem we had ages ago was many fields (including PK) being set to chr(0) by vfp in convoluted scenarios, typically found in last record of table...


>
>Lutz
>
>>It is probably something so basic that you can look at it for minutes without seeing it ;-)
>>If it is not a deleted record with the identical key, no set key, set filter active:
>>copy the file and play with a copy of that copy (so HW goofs are eliminated), perhaps trying to insert, remove first rec, log key, try again
>>same procedure as above, only remove last record on each failure
>>probably do a big facepalm somewhen ;-))
>>
>>
>>>Hi,
>>>
>>>I have a situation with an index error on INSERT INTO
>>>
>>>What I do is basically:
>>>

>>>IF !SEEK(tcKey,cALias,cTAG)
>>> INSERT INTO ...
>>>ELSE
>>> REPLACE ...
>>>ENDIF
>>>

>>>
>>>The code runs for decades
>>>
>>>Today I get an error 1884 on the INSERT INTO on site.
>>>
>>>My errorlog shows:
>>>
>>>cAlias is active area, I am on record 193 of total 194 and I am on EOF(), there is no SET ORDER on this table. Any ideas? Ah, a part of the key is the user ID so it realy shoud not create the same record by accident?
>>>
>>>Lutz