 | |
#1
 
| |||
| |||
|
Backup timing problem. -
07-15-2011
, 09:21 AM
#2
| |||
| |||
|
|
I have a FE / BE database arrangement. The BE contains a TblBackups table about backup information, basically date & time and file size. A form in the FE runs the backup procedure which copies the BE to a memory stick, creates a zip file and emails it to various people. It then creates a new record inthe Tblbackups with the date and file size. Doing it this way, neither the backup on the memory stick or the zip file contain the correct information on the last backup date or file size. If I create the record in the TblBackups before copying the database & creating the zip file, and something goes wrong (not impossible with full memory sticks or emails not working) I then have information that a backup was done when it failed. Any ideas how to overcome this dilemma? Thanks Phil |
size and backup date prior to copying to memory stick and making a zip
file since that is the alst backup date. Is the copying to stick and
zipping done automatically? If so, can't an OnError routine delete
the backup record that contains the file date and size? Are you
automating the email as well? If so, same thing...use an OnError
routine to delete the record.
Or am I, and others, missing additional information on the problem?
#3
| |||
| |||
|
|
On Jul 15, 9:21*am, "Phil" <p... (AT) stantonfamily (DOT) co.uk> wrote: I have a FE / BE database arrangement. The BE contains a TblBackups table about backup information, basically date & time and file size. A form in the FE runs the backup procedure which copies the BE to a memory stick, creat es a zip file and emails it to various people. It then creates a new record in the Tblbackups with the date and file size. Doing it this way, neither the ba ckup on the memory stick or the zip file contain the correct information on th e last backup date or file size. If I create the record in the TblBackups before copying the database & creating the zip file, and something goes w rong (not impossible with full memory sticks or emails not working) I then hav e information that a backup was done when it failed. Any ideas how to overc ome this dilemma? Thanks Phil If I read your email correctly, you want to store the info of file size and backup date prior to copying to memory stick and making a zip file since that is the alst backup date. Is the copying to stick and zipping done automatically? If so, can't an OnError routine delete the backup record that contains the file date and size? Are you automating the email as well? If so, same thing...use an OnError routine to delete the record. Or am I, and others, missing additional information on the problem? |
Yes you undersatnd the scenario perfectly. Both backup and zipping the BE and
sending the email work automatically from a command button on the form,
though the form does have textboxes to tell the code what the memory stick
path is and to whom to email the zip file.
The problem is arrising that before I close the FE Db, I check that a backup
has been done within the last 7 days. On the "live" database this works fine.
However if anyone is looking at the data from the zipped copy (everyone has
the same FE Db) and want to close the program, it comes up with an error
message to say a backup has bot been done because the zip file at the moment
of creation, currently does not have the details of that last backup. Until
that person does a backup, the program can't be closed. A real pain because
the copies can only be used to look at data, and are for information only.
The backups would only ever get written back to the "live" in an emergency.
I think your OnError routine will work although there is a risk that if the
backup gets done but the email fails, the record gets deleted. We then get
the situation that the backup Db says the backup has been done, but there
will be no record in the actual BE Db. Phil
#4
| |||
| |||
|
|
I have a FE / BE database arrangement. The BE contains a TblBackups table about backup information, basically date & time and file size. A form in the FE runs the backup procedure which copies the BE to a memory stick, creates a zip file and emails it to various people. It then creates a new record in the Tblbackups with the date and file size. Doing it this way, neither the backup on the memory stick or the zip file contain the correct information on the last backup date or file size. If I create the record in the TblBackups before copying the database & creating the zip file, and something goes wrong (not impossible with full memory sticks or emails not working) I then have information that a backup was done when it failed. Any ideas how to overcome this dilemma? Thanks |
which is updated at the very end. That is write the record when you
start and then at the very end update the flag.
Personally I'd use a date/time field with Now() in there so I can
moniter how long the entire process takes. As in
BackupCompletedDateTime.
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
#5
| |||
| |||
|
|
On 15/07/2011 19:05:31, Patrick Finucane wrote: On Jul 15, 9:21*am, "Phil" <p... (AT) stantonfamily (DOT) co.uk> wrote: I have a FE / BE database arrangement. The BE contains a TblBackups table about backup information, basically date & time and file size. A form in the FE runs the backup procedure which copies the BE to a memory stick, creat es a zip file and emails it to various people. It then creates a new recordin the Tblbackups with the date and file size. Doing it this way, neither theba ckup on the memory stick or the zip file contain the correct information onth e last backup date or file size. If I create the record in the TblBackups before copying the database & creating the zip file, and something goes w rong (not impossible with full memory sticks or emails not working) I then hav e information that a backup was done when it failed. Any ideas how to overc ome this dilemma? Thanks Phil If I read your email correctly, you want to store the info of file size and backup date prior to copying to memory stick and making a zip file since that is the alst backup date. *Is the copying to stick and zipping done automatically? *If so, can't an OnError routine delete the backup record that contains the file date and size? *Are you automating the email as well? *If so, same thing...use an OnError routine to delete the record. Or am I, and others, missing additional information on the problem? Thanks Patrick. Yes you undersatnd the scenario perfectly. Both backup and zipping the BEand sending the email work automatically from a command button on the form, though the form does have textboxes to tell the code what the memory stick path is and to whom to email the zip file. The problem is arrising that before I close the FE Db, I check that a backup has been done within the last 7 days. On the "live" database this works fine. However if anyone is looking at the data from the zipped copy (everyone has the same FE Db) and want to close the program, it comes up with an error message to say a backup has bot been done because the zip file at the moment of creation, currently does not have the details of that last backup. Until that person does a backup, the program can't be closed. A real pain because the copies can only be used to look at data, and are for information only.. The backups would only ever get written back to the "live" in an emergency. I think your OnError routine will work although there is a risk that if the backup gets done but the email fails, the record gets deleted. We then get the situation that the backup Db says the backup has been done, but there will be no record in the actual BE Db. Phil |
you of that opinion. Could you not have a table (a local one
perhaps..I use/create one called "HoldStuff" in some apps) and in this
table have a flag field called Live (not live as in living but is it a
real live and breathing database application). The files that you
send out have Live set to false. So the external false people don't
care about the backup...due to some code you have written...but the
Live people get warned severely.
#6
| |||
| |||
|
|
Another possibility is to create an additional flag on the record which is updated at the very end. That is write the record when you start and then at the very end update the flag. Personally I'd use a date/time field with Now() in there so I can moniter how long the entire process takes. As in BackupCompletedDateTime. Tony |
No, that doesn't get over the problem, as the original database has 1 more
bit of information (your completed flag) than the copies. Patrick & I seem to
have come up with a solution that works by checking which computer the Db is
being run on.
Phil
#7
| |||
| |||
|
|
On Jul 15, 5:08*pm, "Phil" <p... (AT) stantonfamily (DOT) co.uk> wrote: On 15/07/2011 19:05:31, Patrick Finucane wrote: |
Quote:
|
If I read your email correctly, you want to store the info of file size and backup date prior to copying to memory stick and making a zip file since that is the alst backup date. *Is the copying to stick and zipping done automatically? *If so, can't an OnError routine delete the backup record that contains the file date and size? *Are you automating the email as well? *If so, same thing...use an OnError routine to delete the record. Or am I, and others, missing additional information on the problem? Thanks Patrick. Yes you undersatnd the scenario perfectly. Both backup and zipping the BE and sending the email work automatically from a command button on the form, though the form does have textboxes to tell the code what the memory stic k path is and to whom to email the zip file. The problem is arrising that before I close the FE Db, I check that a bac kup has been done within the last 7 days. On the "live" database this works f ine. However if anyone is looking at the data from the zipped copy (everyone h as the same FE Db) and want to close the program, it comes up with an error message to say a backup has bot been done because the zip file at the mom ent of creation, currently does not have the details of that last backup. Unt il that person does a backup, the program can't be closed. A real pain becau se the copies can only be used to look at data, and are for information only . The backups would only ever get written back to the "live" in an emergenc y. I think your OnError routine will work although there is a risk that if t he backup gets done but the email fails, the record gets deleted. We then ge t the situation that the backup Db says the backup has been done, but there will be no record in the actual BE Db. Phil Ahhh...you say I understand the issue but this question will disabuse you of that opinion. Could you not have a table (a local one perhaps..I use/create one called "HoldStuff" in some apps) and in this table have a flag field called Live (not live as in living but is it a real live and breathing database application). The files that you send out have Live set to false. So the external false people don't care about the backup...due to some code you have written...but the Live people get warned severely. Patrick - you've cracked it - at least put me on the right track. |
Then as I close the database, if the actual Live computer name matches the
ComuterName field I do the backup checks, otherwise just close the Db. Works
a treat. Thanks again
Phil
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.