>>>I have a couple of users that get error 1104, error reading file. Usually this happens on a network station, which tells me that their network connection was lost. The perplexing part is how could the error get logged into the error table if the network were down? Any ideas out there? TIA.
>>>
>>
>>Lots of things can cause this, especially if a large number of files are opened at the same time. Some network clients will 'disconnect' a file prematurely in order to free a connection (seen occasionally with some NT Server versions pre-SP5), or will have the network connections lost because the network's central tracker of network resources (the Browse Master station) forgets about the connection (a known bug in Win95, most comonly encountered in peer-to-peer environment or mixed peer-to-peer and NetWare environments where a Win95 system acts as the network Master Browser). It can also be a result of an intermittent hardware problem, where a connection is broken long enough for some, but not all, network file accesses to time out.
>>
>>>Marcus.
>
>Thanks for the response Ed, and others. I did some tests and noticed when disconnecting the network share that 38 files were open. I then immediately re-established the connection and found that if the network station attempted to use any of those 38 files, it would get error 1104. However, since the errlog.dbf is not one of those 38 files, it has no problem opening file and saving the error. This leads me to the question, is it worth closing and reopening files to avoid this problem? Is their a performance hit for people with stable networks. Maybe it's possible to try to handle this in my error handling routine? Maybe I should leave it as is and try to convince them that their network is having problems. (always a tough sell) What do you think?

An unfortunate reality of file access, network or local, is that the initial open has the greatest single cost of setup of any direct file-related action that you might take. The only thing that might appear to take longer is closing a file where lots of disk writes have been deferred until the system is idle or the file is no longer in use; with a big cache and lots of dirty buffers (a dirty buffer is one where the buffer content is not the same as the data on disk; before a dirty buffer can be safely released, the data must be written to disk. Clean buffers can be discarded immediately and 'recycled') you can be looking at an unpredictably long delay. Closing a file and forcing buffers to flush frequently certainly reduces the risk of data corruption, but there's a big performance penalty exacted.

If an error pops because of an unexpected disconnect, it's too late to deal with the problem in an error handler; if anything bad is going to happen because you lose a connection, the damage has been done when the error is detected.

The problem with trying to convince someone that it's the network at fault when you can't prove out the statement, is that your credibility is shot if you're wrong. If you suspect that there are network problems, it's probably worth the investment to bring in a third party and have them test the network environment for you and your client. If you're right, you're a hero and you've helped your client find the right people to fix the problem at hand, and if you're wrong, you haven't pointed the finger at someone else and said "It's their fault..."

Most small shops don't have the in-house expertise or tools to properly troubleshoot the whole range of potential network problems, especially where you haven't dictated the hardware and NOS environment and may be unsure of driver and hardware compatibility issues that might exist. I pay an attorney to handle contracts, an accountant to make sure that my taxes are filed properly, and a really good mechanic to keep my car running at its best, because that's what they know how to do. I've got pros to come in and service my LAN at work, for the simple reason that i don't have spares on hand, can't afford to wait on replacement parts, and can't afford the $10K-$20K in tools like sniffers and protocol analysers to troubleshoot stuff if things are more involved than a dead port on a hub or busted wire.

YMMV - I've learned enough to know that I'm at least even money to be wrong if something complex breaks a working LAN environment.