MS Access database support - Backing up the front-end from code within the front-end

Author

Backing up the front-end from code within the front-end

rdemyan via AccessMonster.com

2006-04-05, 3:30 am

I have code in my front end that opens a form for backing up the front end.
I'll give a brief description of what the form does:

1) When the backup form opens, it closes all open forms except for three
hidden forms and the backup form itself.
2) It automatically creates a backup name for the front end and displays the
folder where it will be backed up.
3) The user clicks the backup button and the following code executes:

********************
********************
********************
********************
********************
*********
Public Function Database_Backup(Data
base As String, BackupFileName As String)
As Boolean

On Error GoTo Err_Database_Backup

Dim blnComplete As Boolean
Dim fso As Object

blnComplete = False

Set fso = New Scripting.FileSystemObject

If Len(Dir(Database)) = 0 Then

MsgBox "The requested database file does not exist.", vbOKOnly +
vbInformation

Else

fso.CopyFile Database, BackupFileName, True
blnComplete = True

End If

Exit_Database_Backup
:
Set fso = Nothing
Database_Backup = blnComplete
Exit Function

Err_Database_Backup:

If Err.Number = 70 Then
MsgBox "You cannot backup " & Database & " because it is opened
exclusively by another user." & vbCrLf & _
"If you're trying to write the file to a CD, you'll have to do that
from Explorer.", vbOKOnly + vbExclamation Else
MsgBox Err.Number & " - " & Err.DESCRIPTION, vbOKOnly + vbExclamation

End If

Resume Exit_Database_Backup

End Function
********************
********************
********************
********************
********************
*********

Now after six months, I'm having second thoughts as to whether this method
will always work correctly. As far as I know, I haven't had any problems and
I probably average two to three backups per day. It's just that my app is
now so large (170+ forms, 120+ tables), there is no way I can test all of the
functionality of a backup copy.

What precipitated the second thoughts is that I have recently added two
additional hidden forms for sending system messages and for forcing a logoff.

My concern is that I now have four forms open when the front end is copied.
That would be the hidden startup form, two other hidden forms and the backup
form itself, of course. I could, close the two new hidden forms, and then
reopen them. I guess, now that I think about it, I could even close the
startup form just before the filecopy and then load it again after the
filecopy occurs. This would go through the whole startup process again, but
I don't think this would be a major problem.

Any comments on my method and what I'm doing. I just want to make sure that
what I'm doing isn't going to cause me corruption problems or any other type
of problem.

Thanks.

--
Message posted via webservertalk.com
http://www.webservertalk.com/Uwe/Fo...access/200604/1

Jeff Smith

2006-04-05, 3:30 am

rdemyan via AccessMonster.com

2006-04-05, 3:31 am

I want to backup the front-end prior to compacting the front end.

Do you have any comments on my method?

Thanks.

Jeff Smith wrote:
>[quoted text clipped - 5 lines]
>
>My question is "Why do you want to back up the front end?" The front end
>contains the queries, forms, reports, macros and modules. Nothing here
>should change unless you're making modifications to the design of these
>objects. Have you set up the database so every body has their own copy of
>the front end on their PC?
>
>If you're making changes to the front end, you should have a copy of the
>unchanged front end so other people can use the database while you're making
>the changes. That copy of the unchanged front end should be on your backup
>tapes (or other backup media) to be used for recovery purposes. When I'm
>making changes to the front end and there's a lot of changes to make, I
>regularly go to explorer and do a copy and paste of the front end giving a
>file name of "Copy (2) of DBName.mdb". They all have time stamps to find out
>when you made that copy.
>
>Jeff

--
Message posted via webservertalk.com
http://www.webservertalk.com/Uwe/Fo...access/200604/1

Anthony England

2006-04-05, 3:31 am

"rdemyan via webservertalk.com" <u6836@uwe> wrote in message
news:5e4cf302a0656@u
we...
>I have code in my front end that opens a form for backing up the front end.
> I'll give a brief description of what the form does:
>
> 1) When the backup form opens, it closes all open forms except for three
> hidden forms and the backup form itself.
> 2) It automatically creates a backup name for the front end and displays
> the
> folder where it will be backed up.
> 3) The user clicks the backup button and the following code executes:
>
>
> ********************
********************
********************
********************
********************
*********
> Public Function Database_Backup(Data
base As String, BackupFileName As
> String)
> As Boolean
>
> On Error GoTo Err_Database_Backup
>
> Dim blnComplete As Boolean
> Dim fso As Object
>
> blnComplete = False
>
> Set fso = New Scripting.FileSystemObject
>
> If Len(Dir(Database)) = 0 Then
>
> MsgBox "The requested database file does not exist.", vbOKOnly +
> vbInformation
>
> Else
>
> fso.CopyFile Database, BackupFileName, True
> blnComplete = True
>
> End If
>
>
> Exit_Database_Backup
:
> Set fso = Nothing
> Database_Backup = blnComplete
> Exit Function
>
> Err_Database_Backup:

>
> If Err.Number = 70 Then
> MsgBox "You cannot backup " & Database & " because it is opened
> exclusively by another user." & vbCrLf & _
> "If you're trying to write the file to a CD, you'll have to do that
> from Explorer.", vbOKOnly + vbExclamation Else
> MsgBox Err.Number & " - " & Err.DESCRIPTION, vbOKOnly +
> vbExclamation
>
> End If
>
> Resume Exit_Database_Backup

>
> End Function
> ********************
********************
********************
********************
********************
*********
>
> Now after six months, I'm having second thoughts as to whether this method
> will always work correctly. As far as I know, I haven't had any problems
> and
> I probably average two to three backups per day. It's just that my app is
> now so large (170+ forms, 120+ tables), there is no way I can test all of
> the
> functionality of a backup copy.
>
> What precipitated the second thoughts is that I have recently added two
> additional hidden forms for sending system messages and for forcing a
> logoff.
>
> My concern is that I now have four forms open when the front end is
> copied.
> That would be the hidden startup form, two other hidden forms and the
> backup
> form itself, of course. I could, close the two new hidden forms, and then
> reopen them. I guess, now that I think about it, I could even close the
> startup form just before the filecopy and then load it again after the
> filecopy occurs. This would go through the whole startup process again,
> but
> I don't think this would be a major problem.
>
> Any comments on my method and what I'm doing. I just want to make sure
> that
> what I'm doing isn't going to cause me corruption problems or any other
> type
> of problem.
>
> Thanks.

As you have found out, you can take a backup copy while the database is
open - and it will probably be OK. As I suspect you already know, this is
not recommended and if you want to be on the safe side, you should close the
file first. If you close the application first you need some way to restart
it and that will need code in another place - but that could simply be
another mdb file or a vbs file.
The first file could create a prepared shell line, passing in data with the
/cmd option, open the second file and close the first. The second
application now knows which file to backup and re-open.

Rick Brandt

2006-04-05, 9:35 am

"rdemyan via webservertalk.com" <u6836@uwe> wrote in message
news:5e4ec9be21a67@u
we...
>I want to backup the front-end prior to compacting the front end.
>
> Do you have any comments on my method?

In a split environment where each user has their own local copy (the way it
should be) one would normally also have some sort of automatic or semi-automatic
way of distributing new versions. This makes the front end file basically
"disposable". There should be little reason to compact it or back it up because
it can easily be replaced with a new copy.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

Jeff Smith

2006-04-05, 9:35 am

rdemyan wrote
"Now after six months, I'm having second thoughts as to whether this
method
will always work correctly. As far as I know, I haven't had any
problems and
I probably average two to three backups per day. It's just that my app
is
now so large (170+ forms, 120+ tables), there is no way I can test all
of the
functionality of a backup copy."

Haven't you been testing your app during the development? If you have 170
forms then you must have tested them to see if they were working correctly
when you developed them, and also when you made changes to them, and also
when you used other objects to open up those forms. You must have done some
more testing when you finished developing a section of the app.

What do you mean that there is no way that you can test all of the
functionality of a backup copy? A copy is a copy. It should contain all the
objects and functions as the original if there's been no changes to either
copy.

Making a copy of an app that size before any design changes is a good idea
but do you have to incorporate a backup routine into the app just to make a
backup of itself. Are you making changes to the forms or are you
continuously adding new forms? If you're making changes to the forms/reports
there's two ways you can do this: Make a copy of the form/report inside the
app and then make the changes or make the changes in the backup copy and
import that form/report into the main app when finished. The last way means
that you don't do any development in the main front end and it won't get
corrupted, all work is done on a copy.

Jeff

Sponsored Links