Trying again, leaving the HTML out... Hope this will help someone else out...if not today, someday.
I have a client with a network of 43 Win XP systems. All have been accessing a couple of dozen DBF files on a mapped drive (S:\) for several years without problem. Five new workstations running Win7 Pro were installed and from day 1 began having intermittent error #1104 (Error reading file) along with an occasional "corrupt index", "file not found" and other scary errors. These file access errors were always on the Win 7 systems...the XP machines continued running the same VFP 9 SP2 application without error. Each Win 7 system would throw up to 25 to 30 errors every day they were in use. I tried a couple of obvious things that did not help: Network cables...moved the hardware, swapping a Win7 box with an XP system, but the errors followed the Win7 machines. NIC drivers...updated the Realtek NIC drivers to the latest release available. Also, no I/O errors from web browsers, Word, Excel, email applications. The file server is an older Fedora 3 box running Samba 3.08. Per Ted's advice, I looked through the Samba logs and found several repetitive errors that were time-synced with the error reports I was getting from the application. (Ultimately, Googling those errors was what led me to what I hope is the solution below.) I was going to try tweaking some of the KeepAlive settings in the server's Samba and, since there is another server in place on the network running Fedora 12 and Samba 3.4.7, I was also considering moving the DBF files to the new(er) server in case it was a compatibility issue between Win 7 and the older Samba. Did not want to do this as the older server works great...except for this new Windows 7 glitch. One other observation: When the VFP app would throw the 1104 error, if I looked at the drive links displayed in Windows Explorer, the mapped drive S would have a red mark on the icon, indicating that the connection was not active, but VFP would report that the DBF file was in use. My application USEs the DBF file immediately before reading or writing to/from it, then the table is closed as quickly as possible. So, even though VFP would report that the DBF file was opened and ready for access, just milliseconds later when VFP would actually try to read or write to the file, it would throw an 1104 error. It wasn't a solution, but I found that I could restore the connection to the file (and stop the 1104 errors, for a while) by manually clicking on the drive icon in Windows Explorer. But, even though manually clicking to re-establish access would restore the connection, VFP's request for file access through the file API would not. My guess is that the file handle that Windows was providing VFP when it was requested was from a cached pool, instead of being established in real time??? Anyway, hopefully the problem is fixed now as all of the Win 7 machines were in full use for 11 hours today and not one error was thrown. So what fixed it? Registry adjustments on the Win 7 systems. Here's the Microsoft Tech Support page http://support.microsoft.com/default.aspx?scid=kb;en-us;297684 <http://support.microsoft.com/default.aspx?scid=kb;en-us;297684&Product=win2000#appliesto> FWIW, this support article shows to only apply to Win 7 Enterprise (of the Win 7 family), and I'm using Win7 Pro. The article mentions adjusting two registry settings. *HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\autodisconnect *This key did exist on the Win 7 Pro system, and I adjusted it to the maximum value of ffffff hex. The default value that I found on all of the systems was f hex. The other setting the tech support article references did not exist, so I added it. *HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service\lanmanworkstation\parameters\KeepConn* I set this value to the max, also, of 65535 decimal. My understanding is that if you add a registry setting that Windows doesn't use, it won't hurt anything....Windows will just ignore it. Anyway, hope this helps someone. I've been fighting this one for quite a while and even though it's only been 18 hours of error-free operation, I'm hopeful all is well in Hooterville again. Mike _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
