Deploying Access 2007 Runtime-Based Solutions

[Robbo]

I have created an application using Access runtime and it works find. Now,
how do I upgrade the frontend? If I use the same product code or the same
upgrade code it tells me I have to remove the old one first before
re-installing. If I give it a new Product Code it installs the upgrade but I
end up with two entries in the Add/Remove programs list. If I use that
approach I will end up with potentially dozens of extra entries every time I
send out an upgrade. Can anyone tell me how I deploy an upgrade to the front
end? (see http://msdn.microsoft.com/en-au/library/bb501030.aspx)

 

[Albert D. Kallal]

I would suggest that you don't use the packaging wizard to install your
updates. After all the updates are really only a simple file copy anyway.

Furthermore the packaging wizard makes it extremely difficult to overwrite
your files. This is actually probably a good thing because then you don't
have a bunch of users going, hey...cool package wizard lets deploy updates
and then wind up over writing 100's of their clients data (The liability
to you or your organization could be really huge if you screw this up).

So in a way it's probably a really good thing that it's extremely difficult
to overwrite a data file with the packaging wizard.

In fact what I would really suggest you do is you have two separate
installs. One install installs ONLY the runtime and you can use the
package wizard for that.

For any additional front end installs (including the original fe install), I
strongly suggest that you something else. The beauty of this system is in
many cases the user might have office (access) installed and
therefore the download or sending of your simple fe installed will be
very small and all that's required for a successful install .

So, separating the installs makes things a lot more clean and avoids
a really messy situation in which you have to include the runtime
when it actually not needed.

An additional advantage of using some kind of installer is that you can
produce a single exec file for the FE install and it can be easily
downloaded. For a good number of years I actually used a paid version of
WinZip which can produce a self extracting .exe file.

However I now use the free open source installer called inno. You can find
it here

http://www.jrsoftware.org/isinfo.php

make sure you check out the above discussion groups, as is a lot of good
help and how to build scripts.

Even more cool because inno produces a single.exec file, you can actually
build a upgrade routine into your access applications and it's only really
about two lines of code.

eg:

application.hyperlink "url to web site with .exe file"
application.quit.

Take a look the following series of screen shots from one of my act was the
packs is applications in which users are to upgrade their software, you can
see how the life and even a list and I really use much the above technique
(I actually added an FTP program to download for me to eliminate that one
extra prompt about the user having to open or run this file).

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

After my signature in this post of place an example in all script which
would install your front end for you


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(e-mail address removed)


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

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


[Files]
Source: "RidesXP.accde"; DestDir: "{app}"
Source: "RidesXP.dll" ; DestDir: "{app}"
Source: "dynapdf.dll" ; DestDir: "{app}"
Source: "StrStorage.dll" ; DestDir: "{app}"

[Icons]

Name: "{userdesktop}\Rides Reservations (Lodge)"; FileName:
"{reg:HKLM\SOFTWARE\Microsoft\Office\12.0\Access\InstallRoot\,Path}MSACCESS.EXE";
Parameters: """{app}\RidesXP.accde"" /runtime"; IconFilename:
"{app}\Rides.ico"; comment: "Lodge Booking System"
Name: "{group}\Rides Reservations (Lodge)"; Filename:
"{reg:HKLM\SOFTWARE\Microsoft\Office\12.0\Access\InstallRoot\,Path}MSACCESS.EXE";
Parameters: """{app}\RidesXP.accde"" /runtime"; IconFilename:
"{app}\Rides.ico"; comment: "Starts the Rides Booking System"

 

[Allen Browne]

Just replace the accdr file (the front end.)

Rename it if it's an mde.

 

[Robbo]

Thank you so very much for a prompt and thorough reply. Everything you said
makes perfect sense. I really appreciate your kind assistance. As this is my
first time using this service, am I expected to rate your reply etc? If so
how?
--
Cheers
Rob

I would suggest that you don't use the packaging wizard to install your
updates. After all the updates are really only a simple file copy anyway.

Furthermore the packaging wizard makes it extremely difficult to overwrite
your files. This is actually probably a good thing because then you don't
have a bunch of users going, hey...cool package wizard lets deploy updates
and then wind up over writing 100's of their clients data (The liability
to you or your organization could be really huge if you screw this up).

So in a way it's probably a really good thing that it's extremely difficult
to overwrite a data file with the packaging wizard.

In fact what I would really suggest you do is you have two separate
installs. One install installs ONLY the runtime and you can use the
package wizard for that.

For any additional front end installs (including the original fe install), I
strongly suggest that you something else. The beauty of this system is in
many cases the user might have office (access) installed and
therefore the download or sending of your simple fe installed will be
very small and all that's required for a successful install .

So, separating the installs makes things a lot more clean and avoids
a really messy situation in which you have to include the runtime
when it actually not needed.

An additional advantage of using some kind of installer is that you can
produce a single exec file for the FE install and it can be easily
downloaded. For a good number of years I actually used a paid version of
WinZip which can produce a self extracting .exe file.

However I now use the free open source installer called inno. You can find
it here

http://www.jrsoftware.org/isinfo.php

make sure you check out the above discussion groups, as is a lot of good
help and how to build scripts.

Even more cool because inno produces a single.exec file, you can actually
build a upgrade routine into your access applications and it's only really
about two lines of code.

eg:

application.hyperlink "url to web site with .exe file"
application.quit.

Take a look the following series of screen shots from one of my act was the
packs is applications in which users are to upgrade their software, you can
see how the life and even a list and I really use much the above technique
(I actually added an FTP program to download for me to eliminate that one
extra prompt about the user having to open or run this file).

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

After my signature in this post of place an example in all script which
would install your front end for you


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(e-mail address removed)


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

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


[Files]
Source: "RidesXP.accde"; DestDir: "{app}"
Source: "RidesXP.dll" ; DestDir: "{app}"
Source: "dynapdf.dll" ; DestDir: "{app}"
Source: "StrStorage.dll" ; DestDir: "{app}"

[Icons]

Name: "{userdesktop}\Rides Reservations (Lodge)"; FileName:
"{reg:HKLM\SOFTWARE\Microsoft\Office\12.0\Access\InstallRoot\,Path}MSACCESS.EXE";
Parameters: """{app}\RidesXP.accde"" /runtime"; IconFilename:
"{app}\Rides.ico"; comment: "Lodge Booking System"
Name: "{group}\Rides Reservations (Lodge)"; Filename:
"{reg:HKLM\SOFTWARE\Microsoft\Office\12.0\Access\InstallRoot\,Path}MSACCESS.EXE";
Parameters: """{app}\RidesXP.accde"" /runtime"; IconFilename:
"{app}\Rides.ico"; comment: "Starts the Rides Booking System"

 

[Robbo]

Hi Allen,

Thanks for your reply. Makes sense. Appreciate your advice.
--
Cheers
Rob

Just replace the accdr file (the front end.)

Rename it if it's an mde.

 

[a a r o n _ k e m p f]

don't listen to those Jet _FUCKNUTS_

if you want real performance / maintainability-- keep your data--
tables and queries-- in a SQL Server backend and then you won't have
so much trouble with sending out updates to users

Thank you so very much for a prompt and thorough reply. Everything you said
makes perfect sense. I really appreciate your kind assistance. As this ismy
first time using this service, am I expected to rate your reply etc? If so
how?
--
Cheers
Rob

I would suggest that you don't use the packaging wizard to install your
updates. After all the updates are really only a simple file copy anyway.

Furthermore the packaging wizard makes it extremely difficult to overwrite
your files. This is actually probably a good thing because then you don't
have a bunch of users going, hey...cool package wizard lets deploy updates
and then wind up over writing 100's of their clients data (The liability
to you or your organization could be really huge if you screw this up).

So in a way it's probably a really good thing that it's extremely difficult
to overwrite a data file with the packaging wizard.

In fact what I would really suggest you do is you have two separate
installs. One install installs ONLY the runtime and you can use the
package wizard for that.

For any additional front end installs (including the original fe install), I
strongly suggest that you something else. The beauty of this system is in
many cases the user might have office (access) installed and
therefore the download or sending of your simple fe installed will be
very small and all that's required for a successful install .

So, separating the installs makes things a lot more clean and avoids
a really messy situation in which you have to include the runtime
when it actually not needed.

An additional advantage of using some kind of installer is that you can
produce a single exec file for the FE install and it can be easily
downloaded.  For a good number of years I actually used a paid version of
WinZip which can produce a self extracting .exe file.

However I now use the free open source installer called inno. You can find
it here

make sure you check out the above discussion groups, as is a lot of good
help and how to build scripts.

Even more cool because inno produces a single.exec file, you can actually
build a upgrade routine into your access applications and it's only really
about two lines of code.

application.hyperlink "url to web site with .exe file"
application.quit.

Take a look the following series of screen shots from one of my act wasthe
packs is applications in which users are to upgrade their software, youcan
see how the life and even a list and I really use much the above technique
(I actually added an FTP program to download for me to eliminate that one
extra prompt about the user having to open or run this file).

After my signature in this post of place an example in all script which
would install your front end for you

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

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

[Files]
Source: "RidesXP.accde"; DestDir: "{app}"
Source: "RidesXP.dll" ; DestDir: "{app}"
Source: "dynapdf.dll" ; DestDir: "{app}"
Source: "StrStorage.dll" ; DestDir: "{app}"

[Icons]

Name: "{userdesktop}\Rides Reservations (Lodge)"; FileName:
"{reg:HKLM\SOFTWARE\Microsoft\Office\12.0\Access\InstallRoot\,Path}MSACCESS­.EXE";
Parameters: """{app}\RidesXP.accde"" /runtime"; IconFilename:
"{app}\Rides.ico"; comment: "Lodge Booking System"
Name: "{group}\Rides Reservations (Lodge)"; Filename:
"{reg:HKLM\SOFTWARE\Microsoft\Office\12.0\Access\InstallRoot\,Path}MSACCESS­.EXE";
Parameters: """{app}\RidesXP.accde"" /runtime"; IconFilename:
"{app}\Rides.ico"; comment: "Starts the Rides Booking System"- Hide quoted text -

- Show quoted text -

 

[Gina Whipp]

Robbo,

First, let me may sorry for uncalled for remark made by Aaron Kempf. He is
the resident troll and uses language that is either inappropiate to the
forum and it's users AND/OR is incorrect AND/OR does not apply to situation.

Now, that being said... here is a great website that should help you on
your way...

http://allenbrowne.com/tips.html Please scroll down to the bottom. I know
there is another one but it escapes me and hopefully someone else can
provide the link...

 

[Robbo]

Thanks for your comment. I agree that SQL Server is much more stable than
Access as a BE but this application is not big enough to warrant it. Thanks
anyway
--
Cheers
Rob

don't listen to those Jet _FUCKNUTS_

if you want real performance / maintainability-- keep your data--
tables and queries-- in a SQL Server backend and then you won't have
so much trouble with sending out updates to users

Thank you so very much for a prompt and thorough reply. Everything you said
makes perfect sense. I really appreciate your kind assistance. As this is my
first time using this service, am I expected to rate your reply etc? If so
how?
--
Cheers
Rob

I would suggest that you don't use the packaging wizard to install your
updates. After all the updates are really only a simple file copy anyway.

Furthermore the packaging wizard makes it extremely difficult to overwrite
your files. This is actually probably a good thing because then you don't
have a bunch of users going, hey...cool package wizard lets deploy updates
and then wind up over writing 100's of their clients data (The liability
to you or your organization could be really huge if you screw this up).

So in a way it's probably a really good thing that it's extremely difficult
to overwrite a data file with the packaging wizard.

In fact what I would really suggest you do is you have two separate
installs. One install installs ONLY the runtime and you can use the
package wizard for that.

For any additional front end installs (including the original fe install), I
strongly suggest that you something else. The beauty of this system is in
many cases the user might have office (access) installed and
therefore the download or sending of your simple fe installed will be
very small and all that's required for a successful install .

So, separating the installs makes things a lot more clean and avoids
a really messy situation in which you have to include the runtime
when it actually not needed.

An additional advantage of using some kind of installer is that you can
produce a single exec file for the FE install and it can be easily
downloaded. For a good number of years I actually used a paid version of
WinZip which can produce a self extracting .exe file.

However I now use the free open source installer called inno. You can find
it here

make sure you check out the above discussion groups, as is a lot of good
help and how to build scripts.

Even more cool because inno produces a single.exec file, you can actually
build a upgrade routine into your access applications and it's only really
about two lines of code.

application.hyperlink "url to web site with .exe file"
application.quit.

Take a look the following series of screen shots from one of my act was the
packs is applications in which users are to upgrade their software, you can
see how the life and even a list and I really use much the above technique
(I actually added an FTP program to download for me to eliminate that one
extra prompt about the user having to open or run this file).

After my signature in this post of place an example in all script which
would install your front end for you

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

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

[Files]
Source: "RidesXP.accde"; DestDir: "{app}"
Source: "RidesXP.dll" ; DestDir: "{app}"
Source: "dynapdf.dll" ; DestDir: "{app}"
Source: "StrStorage.dll" ; DestDir: "{app}"

[Icons]

Name: "{userdesktop}\Rides Reservations (Lodge)"; FileName:
"{reg:HKLM\SOFTWARE\Microsoft\Office\12.0\Access\InstallRoot\,Path}MSACCESS­.EXE";
Parameters: """{app}\RidesXP.accde"" /runtime"; IconFilename:
"{app}\Rides.ico"; comment: "Lodge Booking System"
Name: "{group}\Rides Reservations (Lodge)"; Filename:
"{reg:HKLM\SOFTWARE\Microsoft\Office\12.0\Access\InstallRoot\,Path}MSACCESS­.EXE";
Parameters: """{app}\RidesXP.accde"" /runtime"; IconFilename:
"{app}\Rides.ico"; comment: "Starts the Rides Booking System"- Hide quoted text -

- Show quoted text -

 

[Robbo]

Hi Gina,

Thanks for your helpful link. Lots of good information in there that will
take me a while to digest.
--
Cheers
Rob

Robbo,

First, let me may sorry for uncalled for remark made by Aaron Kempf. He is
the resident troll and uses language that is either inappropiate to the
forum and it's users AND/OR is incorrect AND/OR does not apply to situation.

Now, that being said... here is a great website that should help you on
your way...

http://allenbrowne.com/tips.html Please scroll down to the bottom. I know
there is another one but it escapes me and hopefully someone else can
provide the link...

 

[Robbo]

The answer here provided is extremely useful but raises one more thought. Is
there a way I can check a hyperlink on the web every time I open my MS Access
FE to see if there's a more up to date front end posted and if so initiate
the download as suggested by Albert D. Kallal?

--
Cheers
Rob

I would suggest that you don't use the packaging wizard to install your
updates. After all the updates are really only a simple file copy anyway.

Furthermore the packaging wizard makes it extremely difficult to overwrite
your files. This is actually probably a good thing because then you don't
have a bunch of users going, hey...cool package wizard lets deploy updates
and then wind up over writing 100's of their clients data (The liability
to you or your organization could be really huge if you screw this up).

So in a way it's probably a really good thing that it's extremely difficult
to overwrite a data file with the packaging wizard.

In fact what I would really suggest you do is you have two separate
installs. One install installs ONLY the runtime and you can use the
package wizard for that.

For any additional front end installs (including the original fe install), I
strongly suggest that you something else. The beauty of this system is in
many cases the user might have office (access) installed and
therefore the download or sending of your simple fe installed will be
very small and all that's required for a successful install .

So, separating the installs makes things a lot more clean and avoids
a really messy situation in which you have to include the runtime
when it actually not needed.

An additional advantage of using some kind of installer is that you can
produce a single exec file for the FE install and it can be easily
downloaded. For a good number of years I actually used a paid version of
WinZip which can produce a self extracting .exe file.

However I now use the free open source installer called inno. You can find
it here

http://www.jrsoftware.org/isinfo.php

make sure you check out the above discussion groups, as is a lot of good
help and how to build scripts.

Even more cool because inno produces a single.exec file, you can actually
build a upgrade routine into your access applications and it's only really
about two lines of code.

eg:

application.hyperlink "url to web site with .exe file"
application.quit.

Take a look the following series of screen shots from one of my act was the
packs is applications in which users are to upgrade their software, you can
see how the life and even a list and I really use much the above technique
(I actually added an FTP program to download for me to eliminate that one
extra prompt about the user having to open or run this file).

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

After my signature in this post of place an example in all script which
would install your front end for you


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(e-mail address removed)


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

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


[Files]
Source: "RidesXP.accde"; DestDir: "{app}"
Source: "RidesXP.dll" ; DestDir: "{app}"
Source: "dynapdf.dll" ; DestDir: "{app}"
Source: "StrStorage.dll" ; DestDir: "{app}"

[Icons]

Name: "{userdesktop}\Rides Reservations (Lodge)"; FileName:
"{reg:HKLM\SOFTWARE\Microsoft\Office\12.0\Access\InstallRoot\,Path}MSACCESS.EXE";
Parameters: """{app}\RidesXP.accde"" /runtime"; IconFilename:
"{app}\Rides.ico"; comment: "Lodge Booking System"
Name: "{group}\Rides Reservations (Lodge)"; Filename:
"{reg:HKLM\SOFTWARE\Microsoft\Office\12.0\Access\InstallRoot\,Path}MSACCESS.EXE";
Parameters: """{app}\RidesXP.accde"" /runtime"; IconFilename:
"{app}\Rides.ico"; comment: "Starts the Rides Booking System"

 

[Tony Toews [MVP]]

The answer here provided is extremely useful but raises one more thought. Is
there a way I can check a hyperlink on the web every time I open my MS Access
FE to see if there's a more up to date front end posted and if so initiate
the download as suggested by Albert D. Kallal?

Yes. I will be adding the same capability sometime to my Auto FE
Updater and to my Granite Fleet Manager app. I came across the
following snippet of code.

First thing I'd do though is create an INI file with the version
number as a line in it and some other information including the name
of the latest version zip file. Then I'd download the INI file. If
it indicated a newer version was available I'd then download the zip
file. You can use the free Info zip DLLs from the link at
Compression DLLs, OCXs, etc
http://www.granite.ab.ca/access/compression.htm as they work well in
Access.

Private Declare Function URLDownloadToFile Lib "urlmon" Alias _
"URLDownloadToFileA" (ByVal pCaller As Long, _
ByVal szURL As String, _
ByVal szFileName As String, _
ByVal dwReserved As Long, _
ByVal lpfnCB As Long) As Long
Public Function DownloadFile(URL As String, _
LocalFilename As String) As Boolean
Dim lngRetVal As Long
lngRetVal = URLDownloadToFile(0, URL, LocalFilename, 0, 0)
If lngRetVal = 0 Then DownloadFile = True
End Function


Pasted from
<http://groups.google.ca/groups?hl=e...1&[email protected]>

===============================================================

You might also find this goody of interest too; it's a function I
wrote to download an http, https or an ftp URL. Note that it doesn't
use
string concatenation which is a killer on performance (if that
matters).
Cheers.

Pasted from
<http://groups.google.ca/groups?hl=en&lr=lang_en&safe=off&selm=uc6$T2qtBHA.2660@tkmsftngp05&rnum=8>


Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Robbo]

Thanks Tony. Very useful. I appreciate the info and will work towards
employing it in my next upgrade

 

[a a r o n _ k e m p f]

you don't need his _SPYWARE_ installed on your machine to do this.
you shoudl just keep your queries and tables in one place- where they
belong-- and email out a _TINY_ frontend when they need a new version

Keep your logic in one place instead of 20
Use SQL Server instead of 100,000 lines of code from some alcoholic
canadian dipshit

-Aaron

The answer here provided is extremely useful but raises one more thought.Is
there a way I can check a hyperlink on the web every time I open my MS Access
FE to see if there's a more up to date front end posted and if so initiate
the download as suggested by Albert D. Kallal?

--
Cheers
Rob

I would suggest that you don't use the packaging wizard to install your
updates. After all the updates are really only a simple file copy anyway.

Furthermore the packaging wizard makes it extremely difficult to overwrite
your files. This is actually probably a good thing because then you don't
have a bunch of users going, hey...cool package wizard lets deploy updates
and then wind up over writing 100's of their clients data (The liability
to you or your organization could be really huge if you screw this up).

So in a way it's probably a really good thing that it's extremely difficult
to overwrite a data file with the packaging wizard.

In fact what I would really suggest you do is you have two separate
installs. One install installs ONLY the runtime and you can use the
package wizard for that.

For any additional front end installs (including the original fe install), I
strongly suggest that you something else. The beauty of this system is in
many cases the user might have office (access) installed and
therefore the download or sending of your simple fe installed will be
very small and all that's required for a successful install .

So, separating the installs makes things a lot more clean and avoids
a really messy situation in which you have to include the runtime
when it actually not needed.

An additional advantage of using some kind of installer is that you can
produce a single exec file for the FE install and it can be easily
downloaded.  For a good number of years I actually used a paid version of
WinZip which can produce a self extracting .exe file.

However I now use the free open source installer called inno. You can find
it here

make sure you check out the above discussion groups, as is a lot of good
help and how to build scripts.

Even more cool because inno produces a single.exec file, you can actually
build a upgrade routine into your access applications and it's only really
about two lines of code.

application.hyperlink "url to web site with .exe file"
application.quit.

Take a look the following series of screen shots from one of my act wasthe
packs is applications in which users are to upgrade their software, youcan
see how the life and even a list and I really use much the above technique
(I actually added an FTP program to download for me to eliminate that one
extra prompt about the user having to open or run this file).

After my signature in this post of place an example in all script which
would install your front end for you

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

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

[Files]
Source: "RidesXP.accde"; DestDir: "{app}"
Source: "RidesXP.dll" ; DestDir: "{app}"
Source: "dynapdf.dll" ; DestDir: "{app}"
Source: "StrStorage.dll" ; DestDir: "{app}"

[Icons]

Name: "{userdesktop}\Rides Reservations (Lodge)"; FileName:
"{reg:HKLM\SOFTWARE\Microsoft\Office\12.0\Access\InstallRoot\,Path}MSACCESS­.EXE";
Parameters: """{app}\RidesXP.accde"" /runtime"; IconFilename:
"{app}\Rides.ico"; comment: "Lodge Booking System"
Name: "{group}\Rides Reservations (Lodge)"; Filename:
"{reg:HKLM\SOFTWARE\Microsoft\Office\12.0\Access\InstallRoot\,Path}MSACCESS­.EXE";
Parameters: """{app}\RidesXP.accde"" /runtime"; IconFilename:
"{app}\Rides.ico"; comment: "Starts the Rides Booking System"- Hide quoted text -

- Show quoted text -

 

[a a r o n _ k e m p f]

CORRECTION!

Jet can't work reliably with even 25mb of data.

'build it nice or build it twice'

-Aaron

Thanks for your comment. I agree that SQL Server is much more stable than
Access as a BE but this application is not big enough to warrant it. Thanks
anyway
--
Cheers
Rob

:

don't listen to those Jet _FUCKNUTS_

if you want real performance / maintainability-- keep your data--
tables and queries-- in a SQL Server backend and then you won't have
so much trouble with sending out updates to users

Thank you so very much for a prompt and thorough reply. Everything you said
makes perfect sense. I really appreciate your kind assistance. As this is my
first time using this service, am I expected to rate your reply etc? If so
how?
--
Cheers
Rob
:
I would suggest that you don't use the packaging wizard to install your
updates. After all the updates are really only a simple file copy anyway.
Furthermore the packaging wizard makes it extremely difficult to overwrite
your files. This is actually probably a good thing because then youdon't
have a bunch of users going, hey...cool package wizard lets deploy updates
and then wind up over writing 100's of their clients data (The liability
to you or your organization could be really huge if you screw this up).
So in a way it's probably a really good thing that it's extremely difficult
to overwrite a data file with the packaging wizard.
In fact what I would really suggest you do is you have two separate
installs. One install installs ONLY the runtime and you can use the
package wizard for that.
For any additional front end installs (including the original fe install), I
strongly suggest that you something else. The beauty of this systemis in
many cases the user might have office (access) installed and
therefore the download or sending of your simple fe installed will be
very small and all that's required for a successful install .
So, separating the installs makes things a lot more clean and avoids
a really messy situation in which you have to include the runtime
when it actually not needed.
An additional advantage of using some kind of installer is that youcan
produce a single exec file for the FE install and it can be easily
downloaded.  For a good number of years I actually used a paid version of
WinZip which can produce a self extracting .exe file.
However I now use the free open source installer called inno. You can find
it here
http://www.jrsoftware.org/isinfo.php
make sure you check out the above discussion groups, as is a lot ofgood
help and how to build scripts.
Even more cool because inno produces a single.exec file, you can actually
build a upgrade routine into your access applications and it's onlyreally
about two lines of code.
eg:
application.hyperlink "url to web site with .exe file"
application.quit.
Take a look the following series of screen shots from one of my actwas the
packs is applications in which users are to upgrade their software,you can
see how the life and even a list and I really use much the above technique
(I actually added an FTP program to download for me to eliminate that one
extra prompt about the user having to open or run this file).
http://www.kallal.ca/ridestutorialp/upgrade.html
After my signature in this post of place an example in all script which
would install your front end for you
--
Albert D. Kallal    (Access MVP)
Edmonton, Alberta Canada
(e-mail address removed)
[Setup]
SourceDir=c:\Documents and Settings\All Users\Application Data\RidesLSP
AppName=Rides Reservation System
AppVerName= Rides SP
DefaultDirName={commonappdata}\RidesLSP
DefaultGroupName=Rides
Compression=lzma
SolidCompression=yes
DirExistsWarning=no
DisableDirPage=yes
DisableProgramGroupPage=yes
Uninstallable=no
[Files]
Source: "RidesXP.accde"; DestDir: "{app}"
Source: "RidesXP.dll" ; DestDir: "{app}"
Source: "dynapdf.dll" ; DestDir: "{app}"
Source: "StrStorage.dll" ; DestDir: "{app}"
[Icons]
Name: "{userdesktop}\Rides Reservations (Lodge)"; FileName:
"{reg:HKLM\SOFTWARE\Microsoft\Office\12.0\Access\InstallRoot\,Path}MSACCESS­­.EXE";
Parameters: """{app}\RidesXP.accde"" /runtime"; IconFilename:
"{app}\Rides.ico"; comment: "Lodge Booking System"
Name: "{group}\Rides Reservations (Lodge)"; Filename:
"{reg:HKLM\SOFTWARE\Microsoft\Office\12.0\Access\InstallRoot\,Path}MSACCESS­­.EXE";
Parameters: """{app}\RidesXP.accde"" /runtime"; IconFilename:
"{app}\Rides.ico"; comment: "Starts the Rides Booking System"- Hidequoted text -
- Show quoted text -- Hide quoted text -

- Show quoted text -