It has been a year since the trouble was fixed. But I'm not sure about what fixed it. Perhaps it was NT SP6. I know I also added FLUSH to force update and added logging to another server. They have registered about 50000 records since then and everything have worked perfect.

Einar


>I think we have encountered the same problem you described!! I really never got any resolution after posting to the Thread. Was wondering if you ever determined the cause and fixed it.
>
>I have a table with a primary key index. If you set the index off an browse we can see records that have all nul data in them. I can determine what the primary fields' data is for the missing records. If we set the index on to the primary key and do a SEEK for the missing record, the pointer ends up on the wrong record. If we set the index off and do a LOCATE we get a !FOUND.
>
>We are still losing records but have just tried some workarounds to resolve. When we create the record we also insert the data into another table. Have just implemented and are not sure if this is going to help.
>
>Pat Chrisco
>
>>I have VFP6.0 SP4
>>
>>Yesterday I visited the lab and found they have a NT server with SP4. The users have NT workstations (SP5 on the one I checked).
>>
>>To investigate this further I created a shared drive on one of the workstations and added code like this on every save:
>>
>>scatter to a
>>select bakorn && On K:
>>seek makorn.kornid
>>IF EOF()
>> APPEND BLANK
>>ELSE
>> IF cTxt='New record'
>> * users hardly look at the screen...
>> DO WHILE MessageBox('Same record found! STOPP!',1+16+256)=2
>> ENDDO
>> ENDIF
>>ENDIF
>>gather from a
>>replace endret with DATE(), tidspunkt with Time(), merknad with cTxt
>>
>>During today there has been no faults adding 1221 new record. And yesterday they added 608 records OK. But monday there was 2 records with binary zeros.
>>
>>Record kornid
>>4301 13391
>>4302 13521
>>4303 13393
>>4430 13520
>>4431 chr(0)
>>4432 13522
>>missing 13392
>>
>>The last operation on 13521 which is stored over 13392 and leaving its record with binary zeros was an update (storing weight before drying the grains). This record must have been read from one place (record #4431) and stored in #4302.
>>
>>The saving in this operation is simply:
>>
>>Set order to parti
>>Seek TRIM(.anlegg1.value)+TRIM(.partinr1.value) && read from a bar-code
>>If !EOF()
>> Replace skaal with .skaal1.value
>> Replace tara with .tara1.value
>> Replace vekt1 with .vekt11.value
>> =TableUpdate()
>> FLUSH
>> unlock
>> .oFrmLogg.Logg('Rått korn') &&logg
>>Else
>> Messagebox('Not in register: '+.anlegg1.value+'-'+.partinr1.value)
>>Endif
>>
>>
>>So how do you explain that the record is written over the kornid-field on record 4302 while the record in 4431 is erased with Chr(0) in all bytes?
>>
>>Could this happen by a corrupt index? (I reindex the tables on programstart if it can open exclusively)
>>
>>No textbox for input on the form is connected to a controlsource. There are some read-only textboxes for displaying current record values.
>>
>>Well, I think I have to wait and see if something happens again. I know the NT SP4 should have been updated, but I should like to prove the errors are caused by something outside my program. Anyway, the duplicated table will make it safe and easy to continue after a server-chrash.
>>
>>Einar