Prev: Eliminating Dates based on a measure
Next: How to convert General date in julian date
From: ThickMike on 27 May 2010 16:19
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?

From: Daniel Pineault on 27 May 2010 16:51
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?
>
From: Tony Toews [MVP] on 28 May 2010 03:57
ThickMike <ThickMike(a)discussions.microsoft.com> 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/
From: David W. Fenton on 28 May 2010 20:03
"Tony Toews [MVP]" <ttoews(a)telusplanet.net> wrote in
news:kltuv5tfv34n7cpp82l12j35qusp1325n4(a)4ax.com:

> 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/
From: ThickMike on 29 May 2010 12:44
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?
>
 | 
Pages: 1
Prev: Eliminating Dates based on a measure
Next: How to convert General date in julian date