Restoring a backed-up database using code

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

Guest

Hello!

I am going to be leaving my job for a (much needed) vacation. While I am
gone, I need to leave a way for others to back up and restore several
databases in case of failures. I've found a viable solution to backup the
database even while it's open using an API call so the "Admins" can do the
backup. However, how would they restore the backend without copying, pasting,
and renaming the latest backup? If it was a matter of only having one backup,
I could use the same API call as above, but there could be several backups
and I need them to be able to choose which one to restore. If it helps, the
backups all have the same naming format, with the system date and time
appended to the end of the file name.

As always, any and all help is greatly appreciated.
~MATT
 
Matt, are you able to share the backup code you found?

I'm very interested in knowing how it solves the time delay that must occur
between copying the first table and the last, and the fact that things may
have changed if the database is actually in use during that time.

Unless that problem is solved, I would not even consider giving unqualified
users the chance to delete all of their data and to replace it with a
potentially inconsistent copy.

If you want to try to write this kind of generic restore functionality
anyway, I imagine it would be a fairly involved task. You would need to
programmatically examine the Relations collection, to determine which tables
depend on which and therefore the order you must follow in order to delete
from your tables and import from the backup. AFAIK, JET permits circular
dependencies, and so your code would need to cope with the fact that there
may not be any possible solution for this. Additionally, you might need to
take into account the effect of any cascading deletes when designing that
process.
 
Allen,

First, thank you!

Wow. OK. Maybe I'm not even in the same ballpark as you on this one. When I
think of backing up the data, I simply copy the existing backend to a
"BACKUP" folder using the API call at
http://support.microsoft.com/default.aspx?scid=kb;en-us;207703. In other
words, I copy the whole backend database.

To restore, I am just copying the backup to the DATA folder and changing the
file names so the backup becomes the data file and the data file becomes
dead. I know this is probably elementary, but it's the only way I really know
to back things up and restore them. If you could point me to an article or
something on the proper way to do this (as opposed to my way...hehe), I would
greatly appreciate it...

~MATT
 
Okay, Matt. Thanks for sharing the source.

The k.b. article you cite does refer to the underlying problem.
Specifically, it says:
WARNING: The following functions enable you to copy an open file.
If the source file is changed while the copy operation is in process,
the destination file may be incomplete or may become corrupted.
AFAIK, there is no resolution to that issue.

It is possible to export the data while the file is in use, and I can give
you code to do that if you like. This will not result in a corrupted file,
but it can result in inconsistent data. That means it needs to be checked by
someone who knows how to check it before it is restored.

The simplest solution is to copy the entire back end mdb while it is NOT
being used. A simple batch file that checks there is no LDB file and copies
the mdb would do the job safely. Then the restore process is just a matter
of getting the network administrator to check no one is using the file, and
replace the existing mdb with the backup one.

That solves all the problems, because it no one is using the file while it
is being backed up/restored.
 
Allen,

Thanks once again for your help here. You guys have no idea how much help
you are to us lesser Access users...hehe.

Anyway, I found out it's going to be my "boss" (long story) doing the
backups, and he understands Access pretty well, so I will pass along the
information you gave about checking for the .ldb file first before backing up
or restoring the databases. My hopes are that nothing goes wrong at all while
I'm gone, but I just know how Murphy's Law insists otherwise. He's usually
here later than anyone that would be using the database anyway, so it should
be easy for him to do the backups with no one in there.

Again, thank you very much!
~MATT
 
Back
Top