Multiple Runtime versions on same machine

[DCrake]

Quick question. Lets say I create a runtime version of an application which is then installed on a machine. I then want to add another one to the same machine, my thoughts are that I only need to deploy the accde/mde to the machine and simply create a shortcut on the desktop that points to that app and it will work in runtime mode. Also the ame goes for product updates, if I deploy a new version of the front end this is all I need to copy to the machine. What I don't want to do is to mak a new installation package for each applet.

Am I correct in my assumptions?

 

[Galaxiom]

One does not really create a "runtime version" of an application.

You can make an executable version (mde/accde) but that will run in the full version if it is installed unless you use the runtime commandline switch. This provides access to the Navigation Bar with the linked tables and queries.

Since you are designing in 2007 I would stick to mde frontends. The accdb/accde adds very little and the implementation is only half baked in 2007. Best practice is to only move to this format if you are working with 2010 which introduces new potentially useful features.

I have never had any problems with running mde in the 2007 runtime. Just need to use the latest version for databases designed in Access 2007 with the service pack.

The big weakness with 2007 accdb/accde is that code signing is only available by package. This is pain for distribution compared to simply opening a signed mde front end.

I use AutoFEUpdater which automatically handles the distribution, runtime switch, upgrade and desktop shortcut. Fortunately I have version 1.7 which does all the important suff for free before Tony went to the paid model. (Sorry Tony, my boss won't pay for anything offered for free.)

AutoFEUpdater can be set up on network shares to runthe front end in the %APPDATA% folder. This keeps most users away from running it in the full version.

 

[boblarson]

One does not really create a "runtime version" of an application.

Umm, that isn't completely accurate. You can package an mdb/mde/accdb/accde/accdr with the Access Runtime in an installer so that the users, if they don't have Access can run it. But there are specific things you must do if you are going to use the Access Runtime instead of a full version of Access. You have to provide all menus/toolbars/ribbons and, if you are going to use a non-compiled file type (mdb/accdb) you have to provide bullet-proof error handling to avoid unhandled runtime errors crashing it. Of course you don't need to do the menus/toolbars/ribbons if your users are going to use a full version of Access but you do if not. So there really is some design thought required for planning on using the runtime.

And while you CAN install multiple versions of the runtime, it is not really a good idea to do so. For one, the swtich between 2003 and 2007/2010 requires the computer to go through the "installation process" somewhat each time you have run one of those versions and then revert to another. This takes a bit longer and is annoying. Also, while there is the possiblity of calling the correct version to start, it is possible for users to end up double-clicking on the access file and it would attempt to start in the last version opened, which might or might not be a problem.

 

[Galaxiom]

One does not really create a "runtime version" of an application.

Umm, that isn't completely accurate. You can package an mdb/mde/accdb/accde/accdr with the Access Runtime in an installer so that the users, if they don't have Access can run it.

Bob, you have missed the point. The runtime version applies to Access, not the application.

While you can produce an installation package to automatically install the runtime version of Access and the application, the application itself (the front end) can only (at best) be converted to an ordinary mde/accde, not a "runtime version of the application".

Users who have the full version of Access will still be able to run the front end in Access without the limitations inherent in the Runtime version of Access providing direct access to the linked tables and query designs.

It is vitally important that anyone reading this thread understands that fact, lest they presume that the Navigation Pane and Design View will be disabled by distributing what they thought was "a runtime version of their application".

 

[DCrake]

All I am trying to get at is lets say the computer does not have Access installed and I package an application which is then installed on the computer. Now down the line they decide to buy another application (which is part of the whole suite but can be bought seperately) can I simply send them the front end which will be installed into a specific folder that is recognised by the application and works in tandem with any other application already resident on the machine. Back ends included.

 

[Galaxiom]

If it is an extension of a base install already having Runtime installed then you can just add the extra application. This is where the signed mde is ideal. The previous "Trust All from Publisher" from the base install approves the new app. The 2007 accde only allows the package to be signed.

Ideally your installer would check the registry for the presence of a version of Access and only install the runtime if necessary.

 

[DCrake]

That's what i was thinking, Never packaged an app yet but my client wants one. Just doing a bit of research first.