>SQL updates disappear.
>
>Here is the code :
>***************
>CURSORSETPROP("Buffering",5,"mytable")
>mid_fld=sys(2015)
>begin transaction
>Update mytable Set id_fld = mid_fld, flag1 = 3, adate3= date() ;
>WHERE mytable .id= some criteria here
>( usually 5 to 10 records are updated)
>
>If ! Tableupdate(1, .T., "mytable")
>=Messagebox("error in updating : mytable”, 16, oApp.Title)
>Rollback
>Return
>ENDIF
>End transaction
>FLUSH
>Select * from mytable where id_fld=mid_fld into cursor Cur2print.
>********
>It selects the records just updated as expected ALL THE TIMES and usually the
>customer produces a hard copy of these transactions.
>
>However in one case (out of the 30 installations of the application ) and in about one out of 20 updates the new values of the fields disappear as though they have never updated (as a proof the customer has a hard copy).
>
>Visual FoxPro 8.0 Service Pack 1
>WINDOWS 2000 SERVER
>As far as I know the only difference from other installations is that there is hard disk mirroring.
>Any explanation ?

It sounds like a buffering issue. I have experienced buffering problems on multiple levels: in the workstation network card (bad nic that was reporting 'success' back through the OS to VFP when, in fact, the card was randomly failing), on the server's hard drive with special hardware level buffering turned on (supposedly a way to make the system appear to be running faster than it was - turned off hardware buffering to fix it), and in registry settings on the server (with NT when Microsoft in it's infinite wisdom actually installed NT server with OpenFiles and Buffering enabled - shouldn't be an issue anymore).

If it is a NIC card then it can be a real problem to hunt down. My client didn't find it until they did a full network analysis with the network probe devices and such. One little card can do a lot of damage.

Since you mentioned hard drive mirroring the possibility of some sort of hardware configuration on the mirrored drive does exist. How you would go about finding that out is a bit of a mystery? Perhaps the only way would be to run the entire system on a temporary server without the mirrored drives and see if the error goes away... In fact, putting in a temporary server that is setup as simply as possible is a good way to determine if the problem 'goes with the server' or 'remains with the network, workstations, and program'. You can possibly eliminate the mirrored drives as a cause by doing that as an elimination test.

Along the same idea you might attempt running with minimum connectivity: 1 server and 1 workstation. Identify all the elements in the connection - cards, os's, routers, wires. And see if the problem exists with all other workstations/equipment turned off. Can it be 'traced' down to a single workstation? Is there a certain place in the program where it seems to occur? Does it occur under a certain threshold of network traffic?

Eventually, you get closer to the solution. But it is time consuming. I have been fortunate with clients understanding the potential for problems to be in the hardware/network/configuration.

Hope you find it!