Einar,

From your descriptions I understand that your application regularly changes an existing key value (kornid) to another value. For instance, record 4430 has kornid of 13520 and record# 4432 has kornid 13522.

While I believe that this *should* be an acceptable thing to do, it could be contributing to the troubles happening here. Like there may be some internal VFP logic condition that is erroneous **in this situation only**.

But as you can tell by now, all this is speculation.

You might want to test the result of the last saving operation you have below, since this seems to be the source of (at least) the observed problem described.

Sorry, and good luck



>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