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
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\autodisconnect
This key did exist on the Win 7 Pro system,
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service\lanmanworkstation\parameters\KeepConn
--- StripMime Report -- processed MIME parts ---
text/html (html body -- converted)
---
_______________________________________________
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.
