Method for restoring front end from a backup

rdemyan via AccessMonster.com

I'm thinking about providing a relatively easy method for users to restore
the front end from a backup. The purpose is to allow for restoring if the
front end becomes corrupt.

Here are some particulars about my app
1) The front end is distributed as a .mde file.
2) Front end uses workgroup security
3) A separate logon form is used to actually launch the front end.
4) My app includes a backup front end form, that backups the front end to the
user's PC. The form automatically creates the backup file name including
date/time.

So here's the process that I'm considering:

1) Put 'Restore Backup' button on logon form.
2) User clicks this button which brings up the file dialogue box. User finds
backup and presses the 'Open' button on the file dialog box.
3) Processing continues and checks that a file name was entered. If not,
message to user.
4) Processing will now attempt to open the selected file and will look for
the version table in the front end. This will assist in verifying that a
backup of the front end was selected and not some other Access file. I
already have this code to check for version updates, so this is a no brainer.
5) If everything is okay, then message asking user to verify that they really
want to restore the backup file.
6) Kill old version, Rename backup version and Filecopy to the main frontend
directory.

I didn't give all the details, but I think there's enough to convey my plan.

I'd like some comments on my plan and I'm curious as to what other's do about
restoring backup copies of the front-end.

I guess another alternative is to ask the administrator to provide a copy of
the master that he/she has. But what if they are not available. Plus I
don't think it is a good idea to leave the master copy in a file folder that
anyone can get to; hence the need to contact an administrator.

Another probaby good option is to just copy a copy of the master from the
server down to the front end.

As I mentioned above I currently have a form in the app that allows users to
backup the front end. They typically will backup the front end to a
subfolder named 'Backups' in the main app folder. I must confess that this
has been an extremely easy method for me, as a developer, to create backups.
However, it might actually be better to force users to just restore a copy
from the server and not from their local PC.

Suggestions, comments, advice are welcome.

Thanks.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200603/1

Mar 29 '06 #1

hugh webster

I am puzzled - if you are using Front-End/Back-End then your Front-End
should contain forms, queries and reports only. All the data should be
elsewhere. So how does it become corrupted?

Anyway, look at the Copy, Rename commands - or create a cmd file - to
reload a clean copy from the server.

On Wed, 29 Mar 2006 20:40:04 +0200, rdemyan via AccessMonster.com
<u6836@uwe> wrote:

I'm thinking about providing a relatively easy method for users to
restore
the front end from a backup. The purpose is to allow for restoring if
the
front end becomes corrupt.

Here are some particulars about my app
1) The front end is distributed as a .mde file.
2) Front end uses workgroup security
3) A separate logon form is used to actually launch the front end.
4) My app includes a backup front end form, that backups the front end
to the
user's PC. The form automatically creates the backup file name including
date/time.

So here's the process that I'm considering:

1) Put 'Restore Backup' button on logon form.
2) User clicks this button which brings up the file dialogue box. User
finds
backup and presses the 'Open' button on the file dialog box.
3) Processing continues and checks that a file name was entered. If not,
message to user.
4) Processing will now attempt to open the selected file and will look
for
the version table in the front end. This will assist in verifying that a
backup of the front end was selected and not some other Access file. I
already have this code to check for version updates, so this is a no
brainer.
5) If everything is okay, then message asking user to verify that they
really
want to restore the backup file.
6) Kill old version, Rename backup version and Filecopy to the main
frontend
directory.

I didn't give all the details, but I think there's enough to convey my
plan.

I'd like some comments on my plan and I'm curious as to what other's do
about
restoring backup copies of the front-end.

I guess another alternative is to ask the administrator to provide a
copy of
the master that he/she has. But what if they are not available. Plus I
don't think it is a good idea to leave the master copy in a file folder
that
anyone can get to; hence the need to contact an administrator.

Another probaby good option is to just copy a copy of the master from the
server down to the front end.

As I mentioned above I currently have a form in the app that allows
users to
backup the front end. They typically will backup the front end to a
subfolder named 'Backups' in the main app folder. I must confess that
this
has been an extremely easy method for me, as a developer, to create
backups.
However, it might actually be better to force users to just restore a
copy
from the server and not from their local PC.

Suggestions, comments, advice are welcome.

Thanks.

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Mar 29 '06 #2

rdemyan via AccessMonster.com

I've seen many posts on corruption that include the front end. Albeit, esp.
when distributed as a .mde file, the odds of corruption in the front end are
very low, but still possible.

Also: I have a number of import forms that import huge quantities of data.
The data is imported into a temporary database and after the records are
validated then it is copied to a table located in the backend. All of the
code to do this is in the front end, but no data is stored in the front end
even temporarily.I thought that this method would prevent any bloat from
occurring in the front end. It did not. There was still signficant bloat in
the front end. I don't know why, but I did document the size of the front-
end and temporary database as the import proceeded.

So, this restore is more of a fail-safe method.

hugh webster wrote:

I am puzzled - if you are using Front-End/Back-End then your Front-End
should contain forms, queries and reports only. All the data should be
elsewhere. So how does it become corrupted?

Anyway, look at the Copy, Rename commands - or create a cmd file - to
reload a clean copy from the server.

I'm thinking about providing a relatively easy method for users to
restore

[quoted text clipped - 63 lines]

Thanks.

--
Message posted via http://www.accessmonster.com

Mar 29 '06 #3

hugh webster

We are talking about 2 different things.

Corruption is a disaster, but Bloat is - unfortunately - normal Access
behaviour.
Even if the data is in external tables, the operations take place in the
Front-End - so it will expand to get the space it needs (but does not
contract afterwards).

There is a CompactDatabase method somewhere in DBEngine, or Workspace but
I don't suppose you can call that from the database itself.

Why not ask the admins to include "upload a clean copy of the Front-End"
in each User's login script?

On Wed, 29 Mar 2006 23:24:48 +0200, rdemyan via AccessMonster.com
<u6836@uwe> wrote:

I've seen many posts on corruption that include the front end. Albeit,
esp.
when distributed as a .mde file, the odds of corruption in the front end
are
very low, but still possible.

Also: I have a number of import forms that import huge quantities of
data.
The data is imported into a temporary database and after the records are
validated then it is copied to a table located in the backend. All of
the
code to do this is in the front end, but no data is stored in the front
end
even temporarily.I thought that this method would prevent any bloat from
occurring in the front end. It did not. There was still signficant
bloat in
the front end. I don't know why, but I did document the size of the
front-
end and temporary database as the import proceeded.

So, this restore is more of a fail-safe method.

hugh webster wrote:

I am puzzled - if you are using Front-End/Back-End then your Front-End
should contain forms, queries and reports only. All the data should be
elsewhere. So how does it become corrupted?

Anyway, look at the Copy, Rename commands - or create a cmd file - to
reload a clean copy from the server.

I'm thinking about providing a relatively easy method for users to
restore

[quoted text clipped - 63 lines]

Thanks.

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Mar 30 '06 #4