[AccessD] Runtime Vs Full Access Install

Charlotte Foust cfoust at infostatsystems.com
Tue Aug 2 12:07:45 CDT 2005


The package can only include redistributable libraries.  I have no idea
whether the FP dlls are redistributable, but if they are not, then they
can't be included in the package, period.  In general, the libraries for
other Office apps are not redistributable.

Charlotte Foust


-----Original Message-----
From: Steve Conklin (Developer at UltraDNT) [mailto:Developer at ultradnt.com]

Sent: Tuesday, August 02, 2005 10:00 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Runtime Vs Full Access Install


I agree with Charlotte, and have been using the same methods for a long
time.  I   do a runtime package for any mdb that I deliver, even the
user has/will use full Access, to ensure that everything, MSCOMCTL and
anything else DLL or OCX-wise, all goes in the application's folder, so
I don't have to worry about any upgraded components in \system32 or
anywhere else.

But I late-bind my Office calls to avoid problems with versioning; I
don't know the answer to Kath's original question concerning Front Page
calls.  Does Access runtime packager include the Office type-libs if
they are called in the application? I don't know - we can provide Access
apps to users w/o Access, but can we do a mail-merge if they don't have
Word? (doubt it)  Further, Front Page was pushed out of Office in ver.
2003,  I don't know if that has any baring on the answer or not.

Maybe late-binding the FP call, and trapping for "Object not created" is
the best answer regardless.


Just my .02,
Steve


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte
Foust
Sent: Tuesday, August 02, 2005 11:47 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Runtime Vs Full Access Install


Then you're very fortunate to have that much control, William, but I
must disagree with you.  Your runtime files are NOT dependent on how the
user does an Access install unless you unwisely (no pun intended)
install the runtime in a generic location where it can be easily mucked
up.  We install the runtime files in their own directory and have not
run into any collisions with installed versions of Access, either before
or after the installation of the runtime.  We've been doing this for
years through multiple versions of Access (and Windows), so I think you
can say it is time tested.  

The only real issue with runtime and full install on the same machine is
that you MUST start the application using a shortcut that specifically
points to the runtime executable or Windows will try to load the last
full version of Access to open the database, whether or not it is
appropriate.

Charlotte Foust


-----Original Message-----
From: William Hindman [mailto:dejpolsys at hotmail.com] 
Sent: Monday, August 01, 2005 8:53 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Runtime Vs Full Access Install


Kath ...afaik the runtime is a "package" at install only ...but if a
user 
subsequently installs full Access ...any version ...all bets are off
because 
your runtime files integrity is dependent upon how the user does the
install 
..a "default" install will screw your runtime more often than not
because 
it defaults to removing older file versions, even if they are needed by
your 
runtime ...Wise/Sage won't block that type of problem from happening
either 
but when you reinstall your runtime they will handle the concurrent full

version issues for you.

..I work with no full Access installs allowed on client systems with the

exception of developer dedicated workstations ...and no "office"
upgrades 
either even if they don't include Access, except by me ...the latter
because 
the office vba modules share some common parts with Access vba.

..but I'll be the first to admit that most developers don't have that
type 
of control over their app runtime environments and there may well be
other, 
better ways to deal with it ...I just find that keeping it clean makes
my 
life a lot simpler and my clients with a lot fewer problems.

William

----- Original Message ----- 
From: "Kath Pelletti" <KP at sdsonline.net>
To: <AccessD at databaseadvisors.com>
Sent: Monday, August 01, 2005 9:04 PM
Subject: Re: [AccessD] Runtime Vs Full Access Install


William - maybe I have misunderstood. I thought that by including all
dll's 
(or other files referred to in the vba references)  in the runtime
install 
package, that it could then be standalone. By that I mean that it would
run 
regardless of whether the user had (any version of Access) or not, as it
is 
a packaged entity.

Have I got that wrong? (And I am assuming using Sage / Wise)

Kath


----- Original Message ----- 
  From: William Hindman
  To: Access Developers discussion and problem solving
  Sent: Thursday, July 28, 2005 3:26 PM
  Subject: Re: [AccessD] Runtime Vs Full Access Install


  ..hhhmmm ...either I'm misreading you or there is a fundamental
  misunderstanding somewhere in here ...a runtime mdb/mde is exactly the

same
  as a full install mdb/mde ...the difference is that Access itself is
not
  fully installed in a runtime ...the design/coding elements are not
there 
so
  a user can't change anything ...it runs exactly as you designed it to
run.

  ..if you have an A97 mdb and an A2k runtime it should still run as
long as
  the references are there ...but the reverse is not true ...so I use 
startup
  code to check the installed version and call the corresponding fe
mdb/mde.

  ..if you invest in the wise install tools, they handle those issues
much
  better than the native Access distribution tools do and the default is
to
  let them do all the work for you.

  William

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



More information about the AccessD mailing list