>>>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...

What made me think of it was the large 450MB table size. I used to see it on the main transactions table of one of my apps, which had over a million rows and was c. 100MB IIRC. I wonder if native VFP tables are more vulnerable to acquiring unwanted CHR( 0 )s when they get "large".