BackEnd copy as Safety Backup

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi All, and thanks for reading!

I have an Access system in a little company with ca. 5 users. All user has a
FrontEnd and there is a BackEnd on a server. All are in Access 2002 and
should stay in this version.

I'd like to make up a backup system for the BE. I decided that each FE
copies automaticaly the BE onto the client computer intervally.

Question: If other users are connecting to the BE when a client tries to
make a copy of it, what kind of problems might I face? (For copy making I use
Scripting.FileSystemObject.)

I tested the system, the backup seems to be usable, is not corrupted, or
demaged. But:
- Is there any differences between the closed and the used BE mdb? If so,
what are the differencies?
- If a record is currently being deleted or edited, should it cause
corruption or demage in the copy? Or just a not-up-to-date record in the copy?

If it is possible, please write me experiences too.

Thanks for any answer in advance!

Bence
 
You should never copy an open database, as there's no way of knowing whether
it'll be in a consistent state.

At least check whether or not the locking file (.ldb) exists before trying
to copy the file: if it doesn't, then you should be fine.
 
AFAIK, there is no safe way to copy an MDB file that is in use. There are
all kinds of potential issues, such as uncommitted transactions, unwritten
buffers, locking strategies, conflicts, replication scenarios, the chance
that the data is being changed fast while you are trying to copy the field
(e.g. action query executing), and so on. So, while the chance of getting a
corrupted file on any particular occasion might be small, it is not an
acceptable strategy since a corrupted file is worthless.

An alternative is to export the tables, in sequence, to a backup database.
This will not generate a corrupt file, but in can generate an inconsistent
one. For example, if Table99 has records related to Table1, you might copy
Table1 successfully, and then before your routine gets to Table99 a
user/process adds a new record to Table1 and a related record to Table99.
When you do get to copying Table99, it then has a record that does NOT
relate to any record in Table1. There is also the chance that a table might
be locked at the particular time you attempt to copy it, and so the back up
actually lacks this table completely.

But at least the inconsistent/incomplete file is not corrupt, so it might
have some value. If you have a scenario where you it this is worth the risk
(a partial backup is better than none), there is some code to execute the
inconsistent backup in this link:
http://allenbrowne.com/unlinked/Backup.txt
 
Back
Top