Copying (backing up) a database from WITHIN that that database?

  • Thread starter Thread starter Howard
  • Start date Start date
H

Howard

Hi,
I'd like to have a button (with a caption of Backup!) make a complete copy
of the current database, i.e. the one that has the button in it. However,
when the database is open and my button showing I cannot copy it and when it
is closed and I can copy it, I obviously can't see the button.
Can it be done?
Howard
 
Howard said:
I'd like to have a button (with a caption of Backup!) make a complete copy
of the current database, i.e. the one that has the button in it. However,
when the database is open and my button showing I cannot copy it and when it
is closed and I can copy it, I obviously can't see the button.
Can it be done?
Click to expand...


Whether it can be done or not, you shouldn't do it. An open
file (especially a database) is in an unknown state and
copying it may produce an unusable file.
 
Marshall Barton said:
Whether it can be done or not, you shouldn't do it. An open
file (especially a database) is in an unknown state and
copying it may produce an unusable file.
Click to expand...


So what is the ethical way to build an application that ensures security of
data by automatically backing it up?
(Word, Excel and most other things have a 'Save As' that will do the trick
when put into a macro)

Howard
 
Databases are fundamentally different from word processors
and spreadsheets. But, any file that is being accessed by
multiple users can be in an unknown state so a copy can't be
reliable. Even a single user Access/Jet application is
multithreaded so, internally, it too is multi user. Even
the Compact action closes the database before doing its job.

What all that means is that before I can try to make
suggestions on how to backup an open file, I would have to
know the details about your application. How it is
structured, single file or split into front end - back end?
If split, I presume it's the back end you want to back up?
How is the database used, a single user, ocassionally by a
few users, 24/7 by hundreds of users?

Regardless of the answers to those questions, the way you go
about it will not be as simple as using a FileCopy command.
The obvious trivial approach is to do it manually at a time
when you know that nobody is using the application, but even
that assumes that some human is a reliable part of the
process.

To do it with a button in the application, means that you
have to have code that ensures that the data file is closed
before using FileCopy. (Most likely you tried it and came
to the newsgroups because FileCopy flat out refuses to copy
an open file.)

If your database is not split, then you need to use another
program to do the backup. See Michael Kaplan's TSI SOON
utility at http://www.trigeminal.com/ for a good way to
control that kind of operation.
 
OK, thank you.
In fact I was asking this on behalf of one of my students who doing a
project towards his final exams. He is required to ensure 'the application
provides the user with a means a means of keeping the database secure' (if
really used at all, this db would be single exclusive user, currently not a
split db but it could be).
Asking the user to do it manually might be ok but then the application is
not really doing it.

I thought of using a VB6 front end (i.e a separate VB6 program) that
launched the database using the OnLoad event when a form was loaded and then
backed it up after the database was closed but before the VB6 form was
unloaded, checking first for the non existence of a lbd file.

My post was to see whether a similar 'shell' existed in Access i.e. a event
that fires as the application loses its last user and deletes the ldb file
or a way of mimicing compact and closing the db and then copying it
Howard
 
Single user, unsplit would require another application to
copy the file. It's pretty easy to start another program
using the Shell method, so you can use that if you want to
do the file copy automatically as Access is closing. The
Unload event of an always open form is a good trigger to
use. The other program can be written in VB or Access, but
may have to loop/sleep for awhile until the file system
catches up with the ldb delete operation.

If you want to do it with a button on a switchboard type
form, then the TSI SOON utility will take care of a lot of
the issues for you.

Using a VB program to start the Access application is also a
valid approach. This would allow you to do the file copy
either before starting Access or after it exits (still with
all the caveats of checking the ldb first).
 
Back
Top