Welcome to SPN

Register and Join the most happening forum of Sikh community & intellectuals from around the world.

Sign Up Now!

maintaining deployed runtime access applications

Discussion in 'Information Technology' started by jyk, Jul 28, 2006.

  1. jyk

    jyk
    Expand Collapse
    Guest

    I am about to deploy my first access runtime application to a customer. I am
    looking for information about design issues associated with maintaining a
    deployed application (e.g., how to introduce bug fixes or a point release
    after the product has been deployed). I have found articles specific to
    deployment, but not about how to design for ongoing maintenance issues. I'm
    sure there are some design practices that make downstream
    maintenance/upgrades go smoother. Thanks!
    --
    jyk
     
  2. Loading...

    Similar Threads Forum Date
    India Sikhs themselves should first start maintaining dignity of turban Breaking News Aug 8, 2013
    India Maintaining peace in Punjab, our responsibility: Damdami Taksal chief Breaking News Jun 14, 2012
    Maintaining relations or communion Sikh Rehat Maryada Dec 29, 2010
    maintaining our culture Interfaith Dialogues Oct 27, 2007
    Sikh News Army deployed in 22 Punjab districts (Dawn) Breaking News Jan 11, 2008

  3. Larry Linson

    Larry Linson
    Expand Collapse
    Guest

    "jyk" <jyk@discussions.microsoft.com> wrote in message
    news:0D21576C-262C-44EF-85DE-A541A82C9192@microsoft.com...
    >I am about to deploy my first access runtime application to a customer. I
    >am
    > looking for information about design issues associated with maintaining a
    > deployed application (e.g., how to introduce bug fixes or a point release
    > after the product has been deployed). I have found articles specific to
    > deployment, but not about how to design for ongoing maintenance issues.
    > I'm
    > sure there are some design practices that make downstream
    > maintenance/upgrades go smoother. Thanks!


    First and foremost, be sure to separate the front-end (user interface:
    queries, forms, reports, macros, and modules) and the back-end (tables with
    data and relationships). MVP Tony Toews' site,
    http://www.granite.ab.ca/accsmstr.htm, has his freely downloadable "Auto FE
    Updater", or you can just have the users copy a new file, as I describe in
    one of the articles on "versioning" at http://accdevel.tripod.com.

    Most corrections and enhancements can then be accomplished by simply
    replacing the users' front-end, without affecting their data.

    Changing the structure of the data tables is not so easy, because each
    user/site will have filled the tables with their own data. So each such
    change, other than adding a new field, is a "custom job" -- maybe easy,
    maybe not so easy.

    Two sites, certainly not the only ones, with good information on the subject
    of multiuser, client-server, and deployment issues are Tony's (ref'd
    earlier) and MVP Jeff Conrad's site,
    http://home.bendbroadband.com/conradsystems/accessjunkie/treeview.html.

    Larry Linson
    Microsoft Access MVP
     
  4. Rick Brandt

    Rick Brandt
    Expand Collapse
    Guest

    jyk wrote:
    > I am about to deploy my first access runtime application to a
    > customer. I am looking for information about design issues associated
    > with maintaining a deployed application (e.g., how to introduce bug
    > fixes or a point release after the product has been deployed). I have
    > found articles specific to deployment, but not about how to design
    > for ongoing maintenance issues. I'm sure there are some design
    > practices that make downstream maintenance/upgrades go smoother.
    > Thanks!


    Of course the app has to be split One file with just tables and another
    with everything else. Then any updates that only affect the front end
    (which should be most) merely involve replacing that file and establishing
    the links to the data file.

    All of my distributed front end files include a table that allows me to have
    "run at first use" code. This code runs the very first time the front end
    file is opened and then it makes an entry into that local table so that it
    knows that it doesn't need to run that code in the future.

    If the updates involves small changes required in the data file my RunOnce
    routine will execute DAO code to make the necessary modifications to the
    back end. If an update requires extensive changes to the data file I will
    distribute a new blank data file with the new structures and the Run-Once
    code will copy all of the data from the old data file into the new one.

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

Share This Page