We have been getting the "Error Reading File" error on a new implementation of Win2k Server/Citrix/10 users accessing shared files. Microsoft recently updated articles linked to PRB: "Error reading file" Error Message on Windows 2000 Terminal Services http://support.microsoft.com/default.aspx?scid=kb;EN-US;299603 so that the registry edits are the recommended course of action.
Our client is performing the edits today, we are all hoping this will resolve the issue.
This may be fixed. Check out Q272127: "STATUS_UNEXPECTED_NETWORK_ERROR" Error Message
This patch fixed it for us. Thanks! Microsoft is tracking the patch because it is not yet fully regression tested. Also, they are not charging for the support call on this issue. (At least, they didn't charge us!) Christopher Olson
The error "Error reading file" in general appears when the connection to the drive where Fox reads it's data (dbf, cdx, etc) fails. Ususally this happens on a network drive, since they are potential for disappearing;
Depending on IMO the Client-version, this error is shown, or a Network error reading file (etc.) comes first and the Error reading file is not shown (use a simple Dos-machine, and you'll have this one).
So much for the known stuff.
For (WTS ?/) Citrix users this may happen when the connection from the TS-task (user-task within TS) gets disconnected, which Citrix does not report on, but the connection is disconnected explicitly. This can happen when not enough licences are present, and at "some time" Citrix (WTS ?) says : okay, you go now, first pay.
In the end, again a normal Error reading file as described above, but just recognize it.
This by the way, becomes even more fuzzy, knowing that implementing the new licences won't help, unless all of WTS and Citrix is re-installed from the beginning.
Apart from everything, somewhere in the Client is re-connect functionality (may even be a param) which says :
when somehow the connection with the server gets lost, re-connect again. This propably operates on Netware-only. Think of laptops plugged out one day, and plugged in the next day, without logging off and on. IMO this will never work for VFP, and should never be performed. But anyhow, this re-connect functionality is within the Client, and does it's job whenever it's found necessary. This may be any kind of disturbance out of our control.
Now somehwere in TCP/IP and MS stuff, there is this regular disconnect, but no problem, because the Client re-connects automatically. This is indirectly caused by DHCP (Dynamic Host Configuration Protocol) which -when active- once in the few hours asks for the allowance of maintaining the same IP-address; when this occurs (and the answer is "yes", a disconnect follows because of a bug somehwere, and further resulting in an automatic re-connect.
With the above as given facts, IMO there may be various problems on the network-connection resulting in the Error reading file error. In most of cases these are caused by using a wrong version of the Client for the particular situation environment. So no, don't download the latest version, but use the proper one for the situation. As an example, we use MS-clients at Novell, because the Novell-client's all won't work, implied by f.e. Illegal seek offset errors in VFP, usually indicating that something is seriously wrong in the memory of the PC. And yes, Error reading file errors are common in such a situation. What is special in our environment ? I don't know, but after a few weeks try-and-error things are solved. Solved ? not completely ...
Referring to the thread in Terminal Server describing an Error reading file problem ("Im having a problem running a Foxpro executable over Terminal Server. At 4:00 every day ...") we have this similar problem at 5:00 pm every day. A few weeks of this occurring learned that at that time a particular person goes home. Hmm, has to do with it. Because -at intervals- this happens, or just not, after a few months (!!) we learned what caused this, thinking of Logoff from network, switch off PC, switch off monitor, switch off light and those kind of things.
It turned out to be the switchting off of the PC, monitor or lights causing some kind of power-dip (peak ?) influencing the cabling.
This all started to happen since we installed new hubs, using an AC-adapter instead of a transformer inside the hub. Now note that only one person (of course me) gets the Error reading file, and only one person next door causes it, where 8 persons are connected to this same hub where I and the person next door causing it, are connected to.
So much for the description of the "randomly" appearing Error reading file errors, which of course are not random, but hard to detect. But the above is just the background-info for the rather integring next subject :
When this all happens, it comes to me (my PC) in various forms, but limited to approx. 5. One of them is the getting of Error reading file on just some parts of the database (just native dbf), and which parts are always the same ! So I have this table containing a few thousand records, and a Seek of some keys I know by heart, always lead to the Error reading file, while all other Seeks succeed. I note that this shouldn't have anything to do with paticular records (blocks) being in the cache of the PC, since the failing Seeks and succeeding Seeks are always the same. It seems that things go wrong in the Index, where a Seek of a non-existing particular key gives the error ("HCAA") and a Seek of an existing near-by key doesn't ("HCA").
Now in between I again refer to the Terminal Server problem.
Trying to break-down this problem, which originally was presented by the (VFP) app, after a Suspend I put an LINENO() and ... get an Error reading file. Hmm;
Asking for the program-stack, I'm in a system-program which is held in a Procedure (residing on the network) and after a Set Proc To (nothing) the LINENO() doesn't give the error anymore. Okay, this leads to the access of the network, though the Procedure should be in de PC's cache, but maybe the LINENO() needs to access the original (compiled) cource, residing on the network.
Anyone having strange Error reading file errors, should have the above in mind;
For sure it won't be a VFP-problem, but something going wrong in the re-connect which is out of your control;
Whether the re-connect was performed or not, should be visible in the login-time of the connection of the server, which on Novell can be seen under (load) Monitor - Connections or NLIST /A/B/C (don't know about NT); as far as I know and see here, WTS connections are just properly visible on Novell (we don't have Citrix).
When you have the error, and you are logged in for several ours but your connection time shows a few minutes, you 'll know where the error originates from. Know look for the reason of the disconnect.
When DHCP causes it, switch this of (but all have fixed IP-addresses now). When DHCP does not cause it, keep on looking...
-- Peter Stordiau
We've recently put one of our clients on a loader program with local non-shared views and the error reading file is almost non-existing *except* on some of the security tables which are not view based, mostly during login/logout. Even get the memo field missing/invalid from time to time. None of these errors can be reproduced "on demand". They are DHCP based, but IP's are not dynamic assigned, they are static. This is against NT 4.0 server with 95/98 PC's, VFP6.0 SP5, switched/managed hubs, 100Mb/sec, etc.
I have another client who is mostly table based (one main view for a certain screen) and they have been getting Error Writing To File! This occurs about once a day and eventually causes corrupt indexes after about a month. They do not use a loader program for the EXE but they all share. The 1 view definition is currently still shared, also. Trying to convince them to pay me to re-factor this, but they don't want to pay for 10-12 hours of my time. Oh well. They are, however, in the process of updating their network hardware, server, hubs (to switches) and making sure they are not running Net BEUI. I have no control over their Configuration Management (or direct access to anything except 1 workstation via PCAnywhere) They have been through multiple lines of local support (this is a long-distance client), including in-house people. Their system seems to continually get worse after each new person touches it. I hope this new person can help them.
This was some good information you provided here. Thanks! I suspected that MS networking was periodically disconnecting, but I don't know how to prove this to be the case. As far as I know, VFP data requires a static, persistent connection AT ALL TIMES. Any interruption should be considered potentially hazardous. -- Randy Jean
Randy, just to be sure : my description of the disconnection caused by DHCP, occurs even when IP's are not canging. DHCP asks for "must I change IP now ?" and anticipating on a Yes it disconnects (my interpretation). Thus, Yes or No, the disconnect is already there, and after that the re-conect occurs.
And yes, it is easy to see or proove that VFP requires a static connection. So how the MS-strategy -probably encouraged by the IP stuff- ever must be consistent with the MS-knowledge (?) of the needed Fox persistent conenction, I don't know. But maybe MS is not to blame for it, and is it just an unsolvable thing.
To be complete, I myself never prooved this stuff to lead to the Read error, but just found out this behaviour in order to solve Read errors which we still have, and are thus caused by something else. However, the theory remains : it is not allowed.
-- Peter Stordiau
There is a bug in TS redirector, when FoxPro app is on shared drive and user, who logged on first, logs out while others are still on, files are closed improperly which results in file read error. Problem was confirmed by MS earlier this year, I don't know if there is any KB article.
See Q299603 .
We just tested this here, and that is indeed the cause of our "Error Reading File" problems. Thanks, Alex! Do you know of a fix for this?
This only affects Terminal Server installations? -- Randy Jean
Is sharing drives really something to go for ? (except from attaching a CD-Rom remotely). -- Peter Stordiau
Unfortunately I don't have the ticket number to follow up. So far, we just do not map, since on TS you are virtually on the console using local drives. Hopefully W2K SP2 will fix the problem. Should we refactor the topic? Alex Dilman
I am having this same problem but in Windows 2008 R2. I had googled it for about an hour and couldn't find a single reference to this problem in any version after Windows 2003, but it seems it is pretty much alive in newer versions. Right now my main problem is to probe to my client that the situation is not caused by my app but for a bug in Windows 2008 R2. This customer runs a VFP6 app in 3 virtualized app servers running Windows 2008 R2, 250+ concurrent users using TS (around 100 users per server) and a non-virtualized data server running Windows Server 2008 R2 and SQL Server 2008 R2. Although the error presents it selfs with local files, most of the time it affects files in a shared folder.
I ran into this error just recently when a system that had been running just fine for years suddenly crashed so often that the system became unusable. I eventually discovered that the client was losing their mapped drives. After hours of googling around, I ran into this link: https://community.spiceworks.com/topic/1139165-windows-10-losing-mapped-drives?page=1. Apparently, drives mapped as part of the group policy can be set to "Recreate", which Windows 8/10 will do in the background. If this happens while your VFP app is running, you will get an error reading the file form the mapped drive. The solution is to set the mapped drive from "Recreate" to "Update"
Contributors Peter Stordiau, Randy Jean
See Also: Error Writing To File
Category Configuration Management, Category Error Handling, Category VFP Troubleshooting
( Topic last updated: 2016.09.15 11:51:40 AM )