Maybe the most sensible thing to do is remove the backup feature entirely. There's nothing wrong with having one, but its existence seems to suggest to many users it's the best way to make a backup. It's not. It's faster, easier and more reliable to make a copy (or a zip archive) directly in the file system. Such backups can be made as required (e.g., prior to updating the program, or conducting "experiments") and scheduled as part of a regular automated backup routine. Another serious flaw of the internal backup routine is that it requires the program to be functioning correctly to make a valid backup, and to be able to restore it.
For the minor convenience of those who would rather make a backup from within the program, there's a better option. That is a simple
Save as copy function. To be useful, such a function would not be so simple "under the hood." It would have to be able to instruct the file system to make a copy even though the file is in use. In the case of a server connection, that probably means disconnecting while the copy is being made, although there's no way to force other applications to disconnect. I don't understand how it works, but maybe there's some way to do this using "shadow copy" technology.
BTW, for those using a version of Windows that includes the
Shadow Copy feature (Vista and 7?),
ShadowExplorer is a free tool that provides a dramatically better alternative to Window's lame
Properties - Previous Versions. Although no substitute for traditional backup, this is the most convenient way to recover from any mishap that has affected only the current database. My usual automated backup keeps the last seven versions of my database, but I see I also have daily shadow copies for the last 21 days!
