>>I have a customer where the cdx file continues to be corrupted.... I rebuild indexes (i use for this operation an old version of Stonefield Database Toolkit) and after a few time (even 3 times in same morning) i have to rebuild it..... Table's size is 450Mb and in the cdx files i have 35 tags. We works in rdp session on a server with Windows Server 2012 R2 and 32Gb ram. (this is a phisical machine). The users are using my app are from 6 to 10 and this is the table that probably is used by all the users (both for write and read access)......... Someone has had similar problems ? Some suggests.... This customer uses my app since 2005 and we never have had this problem and the table thta now has problems was in some periods larger (near foxpro limits) and we have moved data to another table....
>
>For completeness you might want to check that your version of Stonefield fully supports the version of VFP you're using.
>
>I've seen persistent index problems happen because a character-type field (character, memo etc.) in the table data contains CHR( 0 ) somewhere. No reindexing process could fix it. You could write a utility to check character-type fields in your data for CHR( 0 ).

Oooohhhh, yyyeeeaahhh.... Chr(0) can mess you up totally. In vfp6 plus table buffering plus transactions we sometimes were unable to control Chr(0) messing up a fresh created record - ditched transactions for a while until two pronged attack of vfp9 and heavy fixes in error handling allowed turning transactions on again...

>In a networked multi-user VFP app this would happen due to a workstation crash or a network glitch. On an RDP box those are much less likely, unless your app crashes with a C5 or similar error.

We were not on RDP, but had "normal" errors logically following chr(0) or sudden delete).

>Is the server under pressure e.g. high RAM or CPU utilization?