>>>See http://www.berezniker.com/content/pages/visual-foxpro/vfp-90-versions. Yours is SP1. theirs SP2.
>>>
>>
>>Thank you.
>>
>>From what you know, do you think the fact they have SP2 could be causing frequent error 41 when updating table via OleDb driver from ASP.NET app?
>
>I don't see anything in the MS VFP9SP2_BugFixList.htm file that would indicate there's anything different in the handling of memo fields/files between SP1 and SP2.
>
>It would probably be worth doing some basic checks/maintenance on the problem file(s). One thing would be to scan for occurrences of CHR(0) and eliminate any found (you could check the related DBF(s) as well). If it's one DBF/FPT combination that's the problem, you could create a new, known-good empty DBF/FPT and append the old data to the new table (after cleaning out any garbage such as CHR(0) etc.)
>
>I'm fond of saying that if there's any weakness in the setup of a client's LAN, VFP will "find" it - it will manifest itself as problems with the running of a VFP app, or VFP data file corruption.
>
>Does the client have a solid, properly configured network in place? Is the cabling good, are switches/hubs (and critical computers) protected from power surges/brownouts etc.?
>
>Are the VFP data files stored on a server computer, or on a peer-to-peer workstation? Any errors in the "server's" Event Logs (System, Application)? Has the server computer's data storage volume been checked for file system errors with CHKDSK etc.? Hopefully it's NTFS, not FAT32 (more reliable and fault-tolerant).
>
>Hopefully they don't have users doing dumb things like powering down their workstations with the app running, or killing it via the Task Manager.
>
>Are the workstations reliable? Some users "give up" because they can't get answers or help, so they tolerate workstations that freeze or crash several times a day. If your app is running, there's a good chance open VFP files will get corrupted.
>
>Another of my faves is antivirus. Make sure AV on both the server and workstations is set to not real-time scan VFP data files or temp files in TMPFILES folder locations. Also check for any other utilities that may be intercepting file system calls, such as antimalware/antispyware, so-called "real-time" or "continuous" backup utilities etc.
>
>Chances are something in the above is the cause of the problem. If, however, the client swears on a Bible their network is rock-solid, you may recall that Michel ran into some insoluble problems with the VFP9 OLEDB provider in earlier threads here. A couple of points about that:
>
>- I believe the problems he saw manifested themselves only under fairly heavy load
>- I can't recall if error 41 was one of the problems he saw
>
>You could scan earlier threads for these messages. I'm not sure I would even mention these to a client unless all other possibilities have been exhausted.

First, thank you very much for a detailed input and suggestions.

Users turning off work station or having networking issues should be eliminated since this is an ASP.NET web application. The data tables on the server are updated by this ASP.NET app via calls to VFP Stored procedures; everything reside on the server. I have created a error log file and mostly I see users getting error with either "file cannot be read" or "error 41". I see these errors every single day.

I don't think the application is getting heavy load (but I will check again). The way I judge it is by number of new records created every day in the database. And there are not too many. It could, theoretically, be that the server is used for some other applications and I don't know if that would have any effect.

Anti-virus is not checking the application tables (this is what I was told by IT).

I may just uninstall the VFP OLE DB driver SP 2 and install SP1 just to see if it would make any difference.

Again, thank you for your help.