Method for restoring front end from a backup

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • rdemyan via AccessMonster.com

    Method for restoring front end from a backup

    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.c om

  • hugh webster

    #2
    Re: Method for restoring front end from a backup

    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.c om
    <u6836@uwe> wrote:
    [color=blue]
    > 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.
    >[/color]



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

    Comment

    • rdemyan via AccessMonster.com

      #3
      Re: Method for restoring front end from a backup

      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:[color=blue]
      >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.
      >[color=green]
      >> I'm thinking about providing a relatively easy method for users to
      >> restore[/color]
      >[quoted text clipped - 63 lines][color=green]
      >>
      >> Thanks.[/color]
      >[/color]

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

      Comment

      • hugh webster

        #4
        Re: Method for restoring front end from a backup

        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.c om
        <u6836@uwe> wrote:
        [color=blue]
        > 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:[color=green]
        >> 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.
        >>[color=darkred]
        >>> I'm thinking about providing a relatively easy method for users to
        >>> restore[/color]
        >> [quoted text clipped - 63 lines][color=darkred]
        >>>
        >>> Thanks.[/color]
        >>[/color]
        >[/color]



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

        Comment

        Working...