A Microsoft Office (Excel, Word) forum. OfficeFrustration

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.

Go Back   Home » OfficeFrustration forum » Microsoft Access » General Discussion
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Version Updates



 
 
Thread Tools Display Modes
  #1  
Old May 27th, 2010, 09:19 PM posted to microsoft.public.access
ThickMike
external usenet poster
 
Posts: 9
Default 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  
Old May 27th, 2010, 09:51 PM posted to microsoft.public.access
Daniel Pineault
external usenet poster
 
Posts: 658
Default 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  
Old May 28th, 2010, 08:57 AM posted to microsoft.public.access
Tony Toews [MVP]
external usenet poster
 
Posts: 3,776
Default 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  
Old May 29th, 2010, 01:03 AM posted to microsoft.public.access
David W. Fenton
external usenet poster
 
Posts: 3,373
Default 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  
Old May 29th, 2010, 05:44 PM posted to microsoft.public.access
ThickMike
external usenet poster
 
Posts: 9
Default 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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 06:50 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.