Office 2003 Developer?

  • Thread starter Thread starter Al
  • Start date Start date
A

Al

I am redeploying an upgrade to an Access application that I originally
developed in Office 2000 Developer and was able to create an installation
package that took all of the extensions and Activex controls along to install
on users machines. It was great! I now have Office 2003 Professional and
cannot find a Developer version??? Does it exist? How can I create a
package simalar to the one that Office 2000 Developer did? I am willing to
purchase Office 2003 Developer if its available. I am having a very
difficult time distributing an application that I have recently developed in
Access 2003 and its giving me fits!

Thanks in advance,
Al
 
I don't believe Microsoft's sales access 2003 anymore.

however I suspect you can it on on Amazon, or even ebay.

Do note that the access developer tools and extensions are free for access
2007.


for your version, and previous versions of access, it was a fairly pricey
package.

keep in mind that I think it was 2000 was the last version to have activeX
support.

The a2003 runtime does include the six most common ActiveX controls by
default (treeview, listview, calendar, and a few more). So, if you stick to
the offical suppored ActiveX controls for MS access, you not need to include
any activeX controls, because they are included by default.

However if you're using any third party or any other ActiveX control, then
you'll have to either use a one of many free installers (I use inno), as the
access 2003 deployment wizard does not have provisions for 3rd party ActiveX
controls.
 
I'm using the FMS Total Access Memo control in my application, so what you
told me was very important. Thank you! VSTO would not package my
application as needed if that is the case. I downloaded inno but am unsure
of just how to use it. I went through the process of selecting the Access
database and saw something in the help file about "The recommended way to
install an OCX file" just not sure where to do this. Also when I finished
the first time through, I had an .iss file but I didn't have and executable
file, ie. "setup.exe" Is there supposed to be one if done properly?

Thanks,
Al
 
Al said:
I'm using the FMS Total Access Memo control in my application, so what you
told me was very important. Thank you! VSTO would not package my
application as needed if that is the case. I downloaded inno but am
unsure
of just how to use it.
Click to expand...

There's some great newsgroups for inno.

I would suggest you take the following approach deploy your application with
inno.

I would use Microsoft access to create a runtime only installation (that
means it'll install the runtime, but not do any installing for your
application part of things).

For consistency sake, or if you need a single .exe for the runtme isntall,
you can wrap the resulting runtime installation produced by the package
wizard into an inno install. Keep in mind, we're still using the MS access
and Microsoft's installer to do the runtime install. About the only
advantage of doing such is that you get a single.exe file to install the
runtime as opposed to a CD or the multiple directories that the package
wizard creates (in other words the package wizard really doesn't make
something that's downloadable, or a single file).

the inno script for that looks like:


[Setup]
SourceDir=c:\RidesRunTime
AppName=Rides Runtime System
AppVerName= Rides 1.5
DefaultDirName=c:\RidesRunTime
Compression=lzma
SolidCompression=yes

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


[Files]
Source: "*"; DestDir: "{app}"
Source: "files\*"; DestDir: "{app}\files"
Source: "files\setup\*"; DestDir: "{app}\files\setup"
[Run]
FileName: {app}\setup.exe; Parameters: "/qb"


If you look carefully, you can see in the "run" section, I actually
launching the access package wizard install for this runtime.

There several significant advantages to taking this runtime only
installation, one of them is if the user has access installed, then your
front end or application install part is going to be very small in size.

Furthermore, by developing a separate application "inno" install script, you
can use that install script over and over for creating new updates for your
application. In other words, you going to have to create a udate install
system anyway. So, having this *seperate* script will be used for both the
initial
install, and subsequent later installs and when you want to update the
software. So, you need an install that does not have the runtime
part included anyway. Might as well develop *one* install system that does
both updates, and the original install of your application (that means I'm
suggesting to keep the runtime portion completely separate as an install
as per above).
I went through the process of selecting the Access
database and saw something in the help file about
Click to expand...

A typical access script to install your application will look something
like:

[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: "RidesXP.dll" ; DestDir: "{app}"
Source: "dynapdf.dll" ; DestDir: "{app}"
Source: "StrStorage.dll" ; DestDir: "{app}"
Source: "R1.dll" ; DestDir: "{app}"
Source: "R2.dll" ; DestDir: "{app}"
Source: "R3.dll" ; DestDir: "{app}"
Source: "Rides.ico" ; DestDir: "{app}"
Source: "RidesXP.bmp" ; DestDir: "{app}"

Source: "UnZip32.dll" ; DestDir: "{app}"
Source: "Zip32.dll" ; DestDir: "{app}"


[Icons]

Name: "{group}\Rides (Stampede Reservations)"; Filename:
"{app}\RidesXP.mde"; IconFilename: "{app}\cowboy.ico"; comment: "Starts the
Rides Booking System"
Name: "{userdesktop}\Rides (Stampede Reservations)"; FileName: "C:\Program
Files\Microsoft Office\OFFICE11\MSACCESS.EXE"; IconFilename:
"{app}\cowboy.ico"; comment: "Starts the Rides Booking System"

[Registry]
Root: HKLM; Subkey: "SOFTWARE\Microsoft\Jet\4.0\Engines"; ValueType: dword;
ValueName: "SandBoxMode"; ValueData: "2"
Root: HKLM;Subkey:
"Software\Microsoft\Office\11.0\Access\Security";ValueType: dword;
ValueName: "Level"; ValueData: "1"

----

As mentioned all the above will do is create a directory and copy your mdb
file to the target computer. The above as you also see sets a few
registry settings (sets macro secirty to low so the user can run this
without any nag promots).

"The recommended way to
install an OCX file" just not sure where to do this.
Click to expand...

I'm not installed any ActiveX files with inno, but I can guarantee there
going to be tons of help and examples at the inno site on how to do this...

It should look like:

Source: encodermanager.ocx; DestDir: {app}; Flags: regserver

(but, check out their help and site...)
Also when I finished
the first time through, I had an .iss file but I didn't have and
executable
file, ie. "setup.exe" Is there supposed to be one if done properly?
Click to expand...

Yes, it creates a setup.exe in the folder called "output" from the source
dir.


I'm not sure if you're really aware, but there never was any special
connection between the runtime, and a simple access mdb file database that
you copy to the target machine. They're not connected in any special way at
all, and always could simply copy any database to the target machine, and it
will run by double clicking on that mdb file (with runtime restrictions).
 
Back
Top