Thanks for helping, Jim! Here's the details:

1. VFP3 does not imply win3.11. We don't move to vfp5/6 just because we just don't have enough time to do that :) Most of the workstations are win98 and several are 95.

2. The problem is not tracable to the single users. The "disappearing" records are entered by different users on different machines.

3. Deleted records are eliminated during the overnight processing

4. We ARE using .dbc and triggers, but those are working fine.
The form where new records are entered uses buffering ( MS txtbtns class), and I have code that checks the existence of just entered record in the Save button.
The problem is that a saved record disappears (according to CLAIMNO index) during the day.

5. CLAIMNO is assigned from the special table which hold most recent #. This table is FLOCK-ed, number is incremented, copied to the CLAIMNO, and table UNLOCKed after that.

Thanks again, Jim!

>Well Steve, that all looks pretty good, though VFP3 implies that you are using Win3.x. I wonder if there could be some issue with network I/O between NT and Win3.1? Maybe your Net Admin can check?
>
>Is it possible that these can all be traced to a single user? Just wondering if there might be some quirky mousing/fingering by one person in particular.
>
>Are you recycling deleted records? (though I guess your recent nightly rebuild would eliminate any possible problems with that).
>
>I suppose that you are not using .DBC and rules/triggers with this table. Is there any possibility of a timing problem in how you are assigning CLAIMNO?
>HOW are you assigning the CLAIMNO?
>
>Not much help, I know. But the more we investigate the more chance that someone will come up with something.
>
>Cheers,
>
>Jim N
>>>Can you give us a bit more info Steve?... Like
>>
>>The table has the following structure:
>> 1 CLAIMNO Character 10
>> 2 BATCHNO Character 12
>> 3 INVNO Character 12
>> 4 ID Character 7
>> 5 PROG Character 1
>> 6 COC Character 5
>> 7 DOS Date 8
>> 8 DOBILL Date 8
>> 9 VCODE Character 6
>> 10 PROVCODE Character 9
>> 11 PROVLIC Character 9
>> 12 TOTCHARGE Numeric 8 2
>> 13 TOTPAID Numeric 8 2
>> 14 SERVCODE Character 3
>> 15 SPECCODE Character 3
>> 16 DRG Character 3
>> 17 DODISCH Date 8
>> 18 DAYS Numeric 3 0
>> 19 DIAG1 Character 6
>> 20 PROC1 Character 5
>> 21 USERID Character 10
>> 22 USERDATE Date 8
>> 23 GLACCTNO Character 12
>> 24 CHKREQNO Character 8
>> 25 PAYMETH Character 1
>> 26 PAYCODE Character 2
>> 27 AUTHNO Character 10
>> 28 DENYDATE Date 8
>> 29 REFERNO Character 10
>>
>>
>>>
>>>1) What is the complete index expression?
>>
>>claimno
>>
>>>
>>>2) What network software is in use?
>>
>>We have NT network
>>
>>>
>>>3) How many concurrent users?
>>
>>10-15
>>
>>>4) Is this in a 'production' CDX or an ancillary one?
>>
>>production
>>
>>>5) The version of FP/VFP in use.
>>
>>VFP 3.0
>>
>>>6) Anything else you think might be helpful.
>>
>>Every night the table is being zapped, appended and reindexed, but that doesnt help
>>
>>>
>>>Jim N
>>>
>>>>I have an application which is heavily used on a network. The app is built around a table with 150,000+ records, and about 800 new records added every day.
>>>>The table has 16 indexes in the cdx, and the primary index gets screwed up every day. What happens is that by the end of the day about 10 out of 800 records are missing (meaning if I set order to my primary index, they are not found, but all other indexes find them).
>>>>Just for curiosity I added another index, same as my primary, and watched it for 3 days: this index is updated properly, nothing is missing, while my primary got screwed up again... I thought the problem is because of overuse, but I'm not sure.
>>>>Does anybody knows how to deal with it?