That's the beauty of the system I'm using for backing up the dispatch databases. It's really easy to make (less time to program it than to setup the backup software) and extremely flexible and automatic recovery included. Just make a small program running on your data server that checks for inserted or edited records and if there is one of those just duplicate that record (or the changes as the case may be) to your 'safe data' location. Here's the best part... your program that does this duplication can trap common errors like not being able to read the table (a corrupt header, etc.) or check for errors in the records and if they are there, then the program *automatically* reconstructs the production databases from the 'safe data'. You don't have to do a thing. The users will get an error saying that the databases can't be read or something and then they will restart their client programs with the reconstructed databases. And in case of hardware failure of the server machine, you can build a little routine on the client program to switch over to another server machine if that server is unavailable. Of course, you could probably just go with a Database Server (SQL, etc) to do the same thing but you're talking major money for it and a rewrite of your client programs too.

I noticed you said this was for EDI messages. Although my current major project is an EDI one, I hadn't considered the backup system described above for it until now. I think it would be worth it to port-over to this project because, like you said, it's becoming a 'mission citical multi-user system".

- A Hilton


>Hi,
>
>Many thanks for the contributions.
>
>Evan's understanding of our application is correct ... except that it is the recovery time that is critical to us. We need to be back into a consistent state (from a business perspective) well within 15 minutes of any failure of any kind and with minimum loss of data. Hence, if our backup works, we can replace the database at a known "good" time and replay the transactions (which are in fact EDI messages) that happened since that time.
>
>Our application started off as a Fox 2.5 on one PC and has grown into a mission critical multi-user system. We have not had the luxury of designing for this requirement from scratch ... hence our "quick and dirty" approach of backing up the whole database rather than doing transaction logging. (I guess we will be able to do it properly one day).
>
>However, in the meantime we just want a totally fool proof way of doing this backup to a local and or remote machine whilst the users are working. We are now using "COPY TO" and that seems to be working fine.
>
>Regards
>
>Richard Schneller