>>Sanity check first: table, cdx (plus fpt if it exists) exempted from virus and other scans ?
>>SSD, HD or SSD assisted HD ? Any DDR cache RAM on this disk ?
>>Tried with specific small dedicated SSD for that table alone ?
>>Tried with a RAM disk for that table ?
>>
>>Access/usage pattern of that table C/S ready ?
>>no direct or tablebuffered use only cursoradapter, remote view or SQL handling meant ?
>>Can you describe "typical" R/W access pattern of table (continous access across vs. long idle then large bursts ?)
>>
>>I would not totally rule out SMBx problems if the apps ran under different user accounts...
>>
>As i said. We have 7/10 user working all with rdp on terminal server. All data and still the app are on main drive of the server (c). We access the table directly from foxpro without view or cursoradapter... all the user read and write the table concurrently...
>
When similar error pattern came up on TS we switched to running several VM on 1 physical machine, with each user getting only (different) credentials of 1 VM. Those VM accessed tables shared on the physical machine. We ran 9 VirtualBox Win XP VM on 1 machine, each VM 1GB Ram but cut off from INternet, as it app was for internal use only. XP using SMB1 was fine and fast on 1 physical machine and not really endangered, as that physical machine could be reached only via special tunnel and each VM was not given internet access as app was for internal use only.

Another approach when faced with spurious faults was eliminate shared access - was helped a lot as that app already used CA - all was needed to detach cursors after read and close connection. On caTableUpdate base tables were opened exclusively, cursors were attached again, tableupdate fired.
As only few Application TableUpdates were run per H, exclusive usage of persisting tables
was possible without crippling wait times. Needed a smarter base cursoradapter and specific "bulk update" pattern across many tables seldom per H.

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