If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Version Updates
Sorry for repeating this - previous question was in the wrong forum.
I am writing an application in Access 2000 which travelling employees will load onto their laptops. As they do not have the Access program loaded, they will use Runtime. I anticipate that revisions will be needed over time. Updates might be changes to forms & macros, new forms & macros, data changes, extra fields in tables (must not overwrite existing data) The employees are not techie people and applying an update must be as easy and straightforward as possible. Is there a standard way of coping with Updates to the program? Would I be better off splitting the database into front and back ends? |
#2
|
|||
|
|||
Version Updates
Regardless, you should split your db into front-end and back-end components,
if not for the ease of updating (but there are a number of other reasons too). Your situation is a little special. Normally, people access a split db over a network so you can create a launch tool (bat, vbs,...) to check that they have the proper version and if not get it before opening. I would say you can send updates by e-mail, but then you have security issues with mdbs (and other file types) as attachments and then you are relying on users to perform the update and to do so correctly. This just is not a good idea altogether. In your case, perhaps you could create a vbs, to check whether they are connected to your server, if they are then run a check, otherwise simply open the version you have. -- Hope this helps, Daniel Pineault http://www.cardaconsultants.com/ For Access Tips and Examples: http://www.devhut.net Please rate this post using the vote buttons if it was helpful. "ThickMike" wrote: Sorry for repeating this - previous question was in the wrong forum. I am writing an application in Access 2000 which travelling employees will load onto their laptops. As they do not have the Access program loaded, they will use Runtime. I anticipate that revisions will be needed over time. Updates might be changes to forms & macros, new forms & macros, data changes, extra fields in tables (must not overwrite existing data) The employees are not techie people and applying an update must be as easy and straightforward as possible. Is there a standard way of coping with Updates to the program? Would I be better off splitting the database into front and back ends? |
#3
|
|||
|
|||
Version Updates
ThickMike wrote:
I am writing an application in Access 2000 which travelling employees will load onto their laptops. As they do not have the Access program loaded, they will use Runtime. I anticipate that revisions will be needed over time. Updates might be changes to forms & macros, new forms & macros, data changes, extra fields in tables (must not overwrite existing data) The employees are not techie people and applying an update must be as easy and straightforward as possible. Is there a standard way of coping with Updates to the program? Would I be better off splitting the database into front and back ends? You *must* split the database no matter what direction you go. See the "Splitting your app into a front end and back end Tips" page at http://www.granite.ab.ca/access/splitapp/ for more info. See the free Auto FE Updater utility at http://www.autofeupdater.com/ to make the distribution of new FEs relatively painless.. The utility also supports Terminal Server/Citrix quite nicely. The free Auto FE Updater program, see my sig below, does not at this moment in time, handle offline, disconnected systems where the backend databases which use replication. However it will handle it sometime soon, likely in the next month or so. David Fenton has a wiki on the topic. Doing a search should find it. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/ Granite Fleet Manager http://www.granitefleet.com/ |
#4
|
|||
|
|||
Version Updates
"Tony Toews [MVP]" wrote in
: David Fenton has a wiki on the topic. Doing a search should find it. Not on the topic of splitting, but on the topic of Jet Replication: http://dfenton.com/DFA/Replication/ -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
#5
|
|||
|
|||
Version Updates
Thank you all - very useful
"ThickMike" wrote: Sorry for repeating this - previous question was in the wrong forum. I am writing an application in Access 2000 which travelling employees will load onto their laptops. As they do not have the Access program loaded, they will use Runtime. I anticipate that revisions will be needed over time. Updates might be changes to forms & macros, new forms & macros, data changes, extra fields in tables (must not overwrite existing data) The employees are not techie people and applying an update must be as easy and straightforward as possible. Is there a standard way of coping with Updates to the program? Would I be better off splitting the database into front and back ends? |
Thread Tools | |
Display Modes | |
|
|