Access Runtime

  • Thread starter Thread starter Burgers are King
  • Start date Start date
B

Burgers are King

When the Access 2007 Developer Extensions and Runtime tools were announced I
thought great and as soon as they were released I immediately down loaded and
installed them studied there use and applied then to a database for a
installation on a computer with no Microsoft Access using the ‘Package
Solution Wizard’
Following the instruction I was able to reach page 4 save the Wizard
settings and produce an Installable package which I copied to disk and
successfully installed my Access Application on the stand alone computer.
The directory structure was as follows:
Local Disk C
• Folder Access Application/Application.accdr
o Subfolder Application Data/Data.accdb
o Subfolder Application Backup/DatetimeData.bak
This was great and I thought everything would be OK which it was until an
error (minor but embarrassing spelling was discovered in the Application. No
problem I thought I’ll use the ‘Package Solution Wizard’ containing an
amended version of my Application taking into account the information
provided by Microsoft referring to ‘Changing Product Code’ and ‘Using an
UpgradeCode’
Note. I was not able do uninstall as this would remove the application, the
data and any backups that had been created.
After a full day of changing ‘Product Code’, ‘UpgradeCode’ and ‘Product
Version’ (in every combination I could think of) the result was total
failure. I just could not replace the Application.accdr file with the amended
one. (At this point the silence was broken by the sound of a single shot!!!!
Fortunately it was only it was only the pop of a bottle of beer opening.)
Help is it possible to do what I am trying to do?
Have I missed something?
How about you guys at Microsoft can you throw any light on the subject?
 
All you should have to do is copy the new MDB (or ACCDB or MDE or ACCDE or
whatever you're using) on the machine. No packaging should be required.
 
Thanks Douglas but its not that simple you can only generate an ACCDE file by
runing the package wizard. The person/s using the stand alone computer (which
is at least 1/2 a days travel away) are not computer literate and the lasl
thing I want to ask them to do is state deleting and coppying files. I need
to be able to put something onto a CD so they can just insert and follow
instructions
 
Burgers said:
Thanks Douglas but its not that simple you can only generate an ACCDE
file by runing the package wizard.

Not true. At least it never has been true in any other version of Access so I
would be very surprised if that was the case in 2007. Should just be an option
in Access' menus.
The person/s using the stand alone
computer (which is at least 1/2 a days travel away) are not computer
literate and the lasl thing I want to ask them to do is state
deleting and coppying files. I need to be able to put something onto
a CD so they can just insert and follow instructions

So give them a self extracting zip file. Making them execute a runtime setup
routine is way overkill just for doing updates.
 
Thanks Rick I'll try your solution it may work in the short term, but the
question still remains why carn't I do it through the Package Wizard when all
microsofts documentation indicated that I can?

Reading your responces though I realise that I referes to the file extension
incorrectly in my reply to Douglas I should have written .ACCDR and not
..ACCDE.
Thanks
 
Burgers are King said:
Thanks Rick I'll try your solution it may work in the short term, but the
question still remains why carn't I do it through the Package Wizard when
all
microsofts documentation indicated that I can?

I not sure where that been indicated, but you do realize that is a VERY VERY
VERY VERY VERY VERY VERY good thing that you find it difficult to overwrite
a database file with the wizard. I don't think it takes MUCH imagination on
your part as to the cries of people accidentally inserting their install
disk and it overwrites their data. Heck, just accident running that install
disk in the drive should NOT overwrite your data files. The cries and even
perhaps lawsuits would ensure if a simply install could overwrite the data
files.
Reading your responces though I realise that I referes to the file
extension
incorrectly in my reply to Douglas I should have written .ACCDR and not
.ACCDE.

The "r" extension is not really needed, and all it does is save you using
the /runtime switch in your startup shortcut. I would suggest you use
WinZip, or as mentioned something free like "inno" to update the front end.

Keep in mind there is NO special connection between the runtime and your
accDE file that you distribute to your users. Get the runtime installed (I
usually just package a .txt file). From that point on, updates are a simple
file copy...and I usually use the free inno installer for this....

here is what a inno script looks like:

; SEE THE DOCUMENTATION FOR DETAILS ON CREATING .ISS SCRIPT FILES!

[Setup]
SourceDir=c:\Documents and Settings\All Users\Application Data\RidesL
AppName=Rides Reservation System
AppVerName= Rides 2.0
DefaultDirName={commonappdata}\RidesL
DefaultGroupName=Rides
Compression=lzma
SolidCompression=yes

DirExistsWarning=no
DisableDirPage=yes
DisableProgramGroupPage=yes
Uninstallable=no


[Files]
Source: "RidesXP.mde"; DestDir: "{app}"
Source: "Rides.ico" ; DestDir: "{app}"
Source: "RidesXP.bmp" ; DestDir: "{app}"

*----------------------------

the nice advantage of this system is you get a SINGLE .exe file for the
above install. This means you can use a web link for updates, and with about
one line of code, your users can have the following type of update for their
software:

http://www.kallal.ca/ridestutorialp/upgrade.html

The above install screens are how my ms-access users update their software,
and the screens are what the above script produces....
 
Hi All -

In the above discussion, is it not assumed that the FE and the BE (Data) are
in separate database files? What happens if they are in the same file?

John


Thanks Rick I'll try your solution it may work in the short term, but the
question still remains why carn't I do it through the Package Wizard when
all
microsofts documentation indicated that I can?

I not sure where that been indicated, but you do realize that is a VERY VERY
VERY VERY VERY VERY VERY good thing that you find it difficult to overwrite
a database file with the wizard. I don't think it takes MUCH imagination on
your part as to the cries of people accidentally inserting their install
disk and it overwrites their data. Heck, just accident running that install
disk in the drive should NOT overwrite your data files. The cries and even
perhaps lawsuits would ensure if a simply install could overwrite the data
files.
Reading your responces though I realise that I referes to the file
extension
incorrectly in my reply to Douglas I should have written .ACCDR and not
.ACCDE.

The "r" extension is not really needed, and all it does is save you using
the /runtime switch in your startup shortcut. I would suggest you use
WinZip, or as mentioned something free like "inno" to update the front end.

Keep in mind there is NO special connection between the runtime and your
accDE file that you distribute to your users. Get the runtime installed (I
usually just package a .txt file). From that point on, updates are a simple
file copy...and I usually use the free inno installer for this....

here is what a inno script looks like:

; SEE THE DOCUMENTATION FOR DETAILS ON CREATING .ISS SCRIPT FILES!

[Setup]
SourceDir=c:\Documents and Settings\All Users\Application Data\RidesL
AppName=Rides Reservation System
AppVerName= Rides 2.0
DefaultDirName={commonappdata}\RidesL
DefaultGroupName=Rides
Compression=lzma
SolidCompression=yes

DirExistsWarning=no
DisableDirPage=yes
DisableProgramGroupPage=yes
Uninstallable=no

[Files]
Source: "RidesXP.mde"; DestDir: "{app}"
Source: "Rides.ico" ; DestDir: "{app}"
Source: "RidesXP.bmp" ; DestDir: "{app}"

*----------------------------

the nice advantage of this system is you get a SINGLE .exe file for the
above install. This means you can use a web link for updates, and with about
one line of code, your users can have the following type of update for their
software:

http://www.kallal.ca/ridestutorialp/upgrade.html

The above install screens are how my ms-access users update their software,
and the screens are what the above script produces....
 
Good Morning and Hi to all my readers.
First of all I’d like to thank everybody for their contributions and agree
that there are many ways, some simple, some elegant and all quite practical
to change/update a clients file.
However I think, with all due respect to all that there is a point that is
being missed which is as follows:
Microsoft have provided as part of their customer support a tool, namely
‘Access 2007 Developer Extensions and Runtime’ that I believe from my
experience does NOT function as the support documentation seem to indicates.
Yes it does a very good job of packaging an Access Database including adding
subdirectories where the BE and Backup of the BE can be safely stored, but it
does not seem permit me, the originator (unless I’m doing something wrong) to
distribute an upgraded FE. (What do you mean the car will only go round left
hand corners.)
With regard to comment with lots of VERYs in it, firstly, if you try to run
the original setup it tells you that the application is already installed and
that it must be uninstalled before you can reinstall (who would do that, the
client must have some responsibility for their actions). And secondly when
you create the updated setup you only include the files/applications that you
want update and NOT the data or backup files.
So back to my original questions.
My thanks to all.

--
Still trying


J_Goddard via AccessMonster.com said:
Hi All -

In the above discussion, is it not assumed that the FE and the BE (Data) are
in separate database files? What happens if they are in the same file?

John


Thanks Rick I'll try your solution it may work in the short term, but the
question still remains why carn't I do it through the Package Wizard when
all
microsofts documentation indicated that I can?

I not sure where that been indicated, but you do realize that is a VERY VERY
VERY VERY VERY VERY VERY good thing that you find it difficult to overwrite
a database file with the wizard. I don't think it takes MUCH imagination on
your part as to the cries of people accidentally inserting their install
disk and it overwrites their data. Heck, just accident running that install
disk in the drive should NOT overwrite your data files. The cries and even
perhaps lawsuits would ensure if a simply install could overwrite the data
files.
Reading your responces though I realise that I referes to the file
extension
incorrectly in my reply to Douglas I should have written .ACCDR and not
.ACCDE.

The "r" extension is not really needed, and all it does is save you using
the /runtime switch in your startup shortcut. I would suggest you use
WinZip, or as mentioned something free like "inno" to update the front end.

Keep in mind there is NO special connection between the runtime and your
accDE file that you distribute to your users. Get the runtime installed (I
usually just package a .txt file). From that point on, updates are a simple
file copy...and I usually use the free inno installer for this....

here is what a inno script looks like:

; SEE THE DOCUMENTATION FOR DETAILS ON CREATING .ISS SCRIPT FILES!

[Setup]
SourceDir=c:\Documents and Settings\All Users\Application Data\RidesL
AppName=Rides Reservation System
AppVerName= Rides 2.0
DefaultDirName={commonappdata}\RidesL
DefaultGroupName=Rides
Compression=lzma
SolidCompression=yes

DirExistsWarning=no
DisableDirPage=yes
DisableProgramGroupPage=yes
Uninstallable=no

[Files]
Source: "RidesXP.mde"; DestDir: "{app}"
Source: "Rides.ico" ; DestDir: "{app}"
Source: "RidesXP.bmp" ; DestDir: "{app}"

*----------------------------

the nice advantage of this system is you get a SINGLE .exe file for the
above install. This means you can use a web link for updates, and with about
one line of code, your users can have the following type of update for their
software:

http://www.kallal.ca/ridestutorialp/upgrade.html

The above install screens are how my ms-access users update their software,
and the screens are what the above script produces....
 
Pardon the bluntness, but you'd be pretty foolish to distribute an
application that way.
 
Bluntness pardoned Douglas but try and read and understand what I am saying.
Microsoft seem to be offering something that does not work. Like I said 'You
don't expect this car to go rouind right hand bends as well as lift hand
bends do you'. I'm not interested whether its good, bad, is silly or anything
else to use this tool to distrubute, what I am interested in is an answer to
my original QUESTIONS.
 
Burgers said:
Bluntness pardoned Douglas but try and read and understand what I am
saying. Microsoft seem to be offering something that does not work.
Like I said 'You don't expect this car to go rouind right hand bends
as well as lift hand bends do you'. I'm not interested whether its
good, bad, is silly or anything else to use this tool to distrubute,
what I am interested in is an answer to my original QUESTIONS.

The tools provided by MS to distribute the runtime have sucked badly since
Access 2000 and Access 97 (while a lot better) was still pretty limited compared
to other installers that you can use.

Developers who make serious use of the runtime have almost always used third
party installers because of the limitations of those that come with the package.
Should MS have provided a better product? Sure, but since they haven't done so
for a few decades now, it is no surprise that the one for 2007 (the first free
one mind you) is not any better.
 
As should have been apparent from the trimming I did to the original post,
my comment was aimed at the specific question regarding using a non-split
application.
 
Hi Doug -

Bluntness indeed! I wasn't asking that as a genuine question that I needed
an answer for; I meant it more as a question that others should consider when
discussing this issue. And you are right, of course - distributing updates
of an application that way might tend to shorten one's career.

Cheers!

John
 
J_Goddard via AccessMonster.com said:
Hi All -

In the above discussion, is it not assumed that the FE and the BE (Data)
are
in separate database files? What happens if they are in the same file?

John

If they are in the same file, then you have no real easy way of issuing
updates to your software....

The whole idea of "split" is to endorse the whole concept of the software
process in which you the developer is making and developing software...that
software should be separated from the data..

It makes it VERY difficult to issue updates if you don't split...and even
for single user systems I always split.

If you not seen my article on splitting, you find it here:
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

The thing about the above article is that I don't just tell you to
split...but, in fact explin *WHY* you want to split on a conceptual biases.
 
Bluntness pardoned Douglas but try and read and understand what I am
saying.
Microsoft seem to be offering something that does not work.

You have to show me the documentation that shows how to do updates, it just
a poor tool, and for the most part is not appropriate for updates. We can
wish that it was different, or better...but, 2+2 = 4, and this tool is
really lousy for updates. Is there any part of this English you don't
understand? If you have a document that shows how to do the updates...and it
don't work...then I all ears.

The generally whole developer community has spoken here...and we all
concluded this about 10 or more years ago...
L ike I said 'You
don't expect this car to go rouind right hand bends as well as lift hand
bends do you'. I'm not interested whether its good, bad, is silly or
anything
else to use this tool to distrubute, what I am interested in is an answer
to
my original QUESTIONS.

There is two kinds of people in their world the ones that complain and wine
about every little thing, and never get ahead in life, and then others who
simply look at things...and figure out when to forge on ahead..

the answer is rather simple:here:

The PW tools are REALLY REALLY poor for issuing updates. I wish this was not
the case, but it is. On the other hand this limitation NEVER amounted of to
hill of beans because ay self worth developer would moved on and used
something else. And, furthermore, there is lots of free alternatives out
there.

There is a TON of alternatives available here....if you can't get yourself
around this limitation of the free product..I just can't help you.

If you REALLY want to dig into this, then consider downloading the orca
tools, and tweaking the installs...but, then again, that assumes you have a
lot of time to waste......
http://msdn2.microsoft.com/en-us/library/aa370557.aspx

Depending on you needs, if you need wide distribution and something more
then free the free inno installer, then head on to here:
www.sagkey.com
and
http://www.sagekey.com/access_runtimes.aspx

In a sense, now that the developer tools are free, the sagkey prices are
bargain because you don't need to purchase the developer tools for access
anymore....

An update to your software is a SIMPLE file copy. We really don't need to
waste a LOT of time on how to copy a file..and if we do, then we making the
world a poorer place. The time you save by avoiding the PW could then be
donated to helping feed the poor in your neighborhood....
 
Back
Top