Al,

Thanks, this was helpful.

Jerry


>>We have a VFP 9sp2 EXE that runs 24/7. The EXE and DBFs resides on a network drive.
>>
>>Occasionally the network admins will perform maintenance on the network after hours or on weekends. If the admins ever perform something that interrupts the network, causing our VFP EXE to lose network connection for a moment, our VFP EXE will hang and not perform it's tasks. I usually see an error such as "Error reading file". The app will hang until I re-start the app when I come in the next morning.
>>
>>Is there a way for a VFP application to recover itself after a network connection has been lost and then re-established?
>
>In general, for this type of app you need to code "defensively", assuming as little as possible about the environment in which it's run.
>
>First, run your .EXE from a local drive, not a network drive. If necessary, you can start your program with a batch file, that copies the network .EXE to a local folder and runs it from there.
>
>If you're not already doing so, with this type of app it's usually a good idea to implement one or more rotating log file(s), and instrument your app so it records processing job start datetime, job messages, job stats, processing job end datetime etc. If your app has a user interface you can display the last X log file entries, which can be very useful for anyone monitoring or troubleshooting your app.
>
>With network file I/O and access to network services such as SQL Server, the philosophy should be to minimize the amount of time these services are required, and not to rely on them always being available when you do want them. You need to assume that any file I/O operation might fail, and wrap them in TRY...CATCH blocks or have a comprehensive ON ERROR handler in effect. Even if you wrap code in TRY...CATCH you still need a good ON ERROR handler, to catch and record error conditions you couldn't predict, and which you will certainly see from time to time in an app that runs 24/7.
>
>If an operation fails you will usually want to retry it. One simple but suboptimal way to achieve this is just to put the code in a loop that continues until it succeeds. With modern, fast computers this could generate thousands of file I/O requests per second, and saturate the network as well as pinning the workstation's CPU. A better approach is to wait for a period of time (1 second, 10 seconds, 1 minute etc.) before retrying. To do this you can use techniques such as the Sleep API ( http://news2news.com/vfp/?group=58&function=80 ), which will pause your VFP app and let the workstation do other things, while not saturating the network. It's also a good idea to include DOEVENTS in any retry code that gets looped, to improve the responsiveness of any other apps that may be running simultaneously on the workstation. You may want to write a message to your log file in the event of a failed I/O operation.
>
>You also need to think about making your network operations transactional. For example, suppose you need to open 3 network .DBFs. The first one opens right away, but then the server goes down for 5 minutes. Your fault-tolerant table opening function periodically retries to open the 2nd table, and eventually succeeds. It then opens the 3rd one right away because the server is back up. However, the connection to the first table has been broken and any later operation that relies on it will fail.
>
>In this case, in the event of ANY failure in opening ANY of the 3 tables, you need to close any that seemed to have opened OK, then retry them all. Note that attempting to close a table in these circumstances may fail as well, you have to trap that possibility too!
>
>If you have lengthy processing to do, you might consider copying (e.g. SELECT to cursor(s)) data from the network tables to local storage, close the network tables, then do your processing. When finished, re-open the network tables and write back the results. When writing back you can make use of VFP transactions for improved reliability.
>
>There's no quick fix or magic bullet to improve the reliability of an app that's supposed to run unattended 24/7. You need a healthy dose of paranoia, or great respect for Murphy's Law:
>
>- Assume as little as possible
>- Think about possible failure points and retry intelligently with appropriate error handlers
>- Make I/O operations transactional
>- A good log file is your best friend