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