maintaining deployed runtime access applications

[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!

 

[Larry Linson]

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

 

[Rick Brandt]

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.