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

[rdemyan via AccessMonster.com]

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 (Database As String, BackupFileName As String)
As Boolean

On Error GoTo Err_Database_Ba ckup

Dim blnComplete As Boolean
Dim fso As Object

blnComplete = False

Set fso = New Scripting.FileS ystemObject

If Len(Dir(Databas e)) = 0 Then

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

Else

fso.CopyFile Database, BackupFileName, True
blnComplete = True

End If
Exit_Database_B ackup:
Set fso = Nothing
Database_Backup = blnComplete
Exit Function

Err_Database_Ba ckup:

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_B ackup

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 AccessMonster.c om
http://www.accessmonster.com/Uwe/For...ccess/200604/1

[Jeff Smith]

"rdemyan via AccessMonster.c om" <u6836@uwe> wrote in message
news:5e4cf302a0 656@uwe...

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:

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

[rdemyan via AccessMonster.com]

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:

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:

[quoted text clipped - 5 lines]

folder where it will be backed up.
3) The user clicks the backup button and the following code executes:

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 AccessMonster.c om
http://www.accessmonster.com/Uwe/For...ccess/200604/1

[Anthony England]

"rdemyan via AccessMonster.c om" <u6836@uwe> wrote in message
news:5e4cf302a0 656@uwe...

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 (Database As String, BackupFileName As
String)
As Boolean

On Error GoTo Err_Database_Ba ckup

Dim blnComplete As Boolean
Dim fso As Object

blnComplete = False

Set fso = New Scripting.FileS ystemObject

If Len(Dir(Databas e)) = 0 Then

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

Else

fso.CopyFile Database, BackupFileName, True
blnComplete = True

End If
Exit_Database_B ackup:
Set fso = Nothing
Database_Backup = blnComplete
Exit Function

Err_Database_Ba ckup:

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_B ackup

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]

"rdemyan via AccessMonster.c om" <u6836@uwe> wrote in message
news:5e4ec9be21 a67@uwe...

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]

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