Access XP Runtime (Developer Ed)

[Jason Peak]

After much ado, I'm coming to the conclusion that the Access XP runtime
does not work at all. I've followed the following procedures

1. Performed clean Windows 2000 Professional installation with
Service Pack
2. Installed the Windows Componenent Update included with Office
XP Develope
3. Installed the MS Access XP Runtime, which was created on the
development machine in the "C:\Program Files\Microsoft Office
Developer\Access Runtime\1033\ART" directory
4. Copied a .mdb file that I verified I could open with Access XP
to the desktop of the target machine
5. Double-clicked the .mdb file

At this point, the Access shell popped up with nothing available inside.
Literally nothing... Basically, all I could do was close the shell. I
was doing this just to test to see if my problems were with the runtime,
which they seem to be

My immediate problem is in my visual basic application where I instantiate
my Access.Application object. The vb project has a reference to the Microsoft
Access 10.0 Object library located in the "C:\Program Files\Microsoft OfficeOffice10\" directory. The file MSACC.OLB has been installed and registered
along with the package on the target machine. However, when the code hits the
line "Set accApp = CreateObject("Access.Application"), it errors with the message
"Run-Time Error '429': ActiveX component can't create object.". I've tried this
method of object creation as well as Dim'ming the accApp object directly as
Access.Application and changing the Set command to "Set accApp = New
Access.Application", but it gives the exact same error at the exact same spot.
Both the development machine and the target machine are Windows 2000. I've tried
installing the app on a Win2K service pack 4 machine (same as development machine)
and a Win2K service pack 2 machine (clean machine with only Windows and Access XP
Runtime installed) and get the same result on all

 

[Albert D. Kallal]

Normally, you do use a mde with the runtime, not a mdb.

However, I would do some testing on your development pc. For example, have
you tried running the sample application with the /runtime switch on your
development pc?

A typical runtime switch will look like:

"C:\Program Files\Microsoft Office\Office\msaccess.exe"
"c:\program files\Rides\Rides.mdb"
/wrkgrp "c:\Program Files\Rides\Rides.mdw"
/runtime

I use the above short cut on my dev pc to test the runtime. Using the
runtime switch lets you view/see how your application will run BEFORE YOU
WASTE a bunch of time moving, and testing your install application to the
other pc.

In other words, you do want to test/use and try the application as a runtime
application on your pc. You should get the application working as a runtime
application BEFORE YOU start trying and testing it on another pc.

I also assume that you have built a nice user interface that starts up, and
is set correctly for this sample application. Remember, with the run time,
you don't have the ms-access interface, and must built you own.

Of course, anyone reaching the point of wanting to distribute their software
has not doubt done things like build a nice custom menu interface anyway. I
mean, ask your self, have your EVER installed any software without a menu
system? Since you are now the software developer, then you too must built
and provide the menu UI.

If your existing application relies on the ms-access user interface, then
you are not yet ready to use the runtime. I would assume your application
provides a nice UI, and totally hides the ms-access interface. This the
standard approach for any application development in ms-access, but for the
runtime, it is in fact a requirement as the there is no ms-access interface
included with the runtime. You can spend two minutes and make a tiny menu
with just file->exit on it, and then specify a start-up form. (a lot of
ms-access applications are build that way, and some even still use/rely on
the switch board. However, if you have actually reached the point of being
ready to deploy your application, then I would assume you have long ago
built a nice UI that hides the ms-access stuff.

If you need some ideas as to the approach for a menu in ms-access you can
read the following UI ideas of mine. All of the screen shots are from
ms-access, but the end users never really do know this fact.

http://www.attcanada.net/~kallal.msn/Articles/UseAbility/UserFriendly.htm

 

[Paul Overway]

You cannot instantiate the Access runtime...only retail version.
CreateObject will always fail.

Your description of opening your app implies that you have not created
menus, toolbars, set a startup form, etc.. This should be expected. You
have work to do yet.

--
Paul Overway
Logico Solutions, LLC
www.logico-solutions.com

After much ado, I'm coming to the conclusion that the Access XP runtime
does not work at all. I've followed the following procedures:

1. Performed clean Windows 2000 Professional installation with
Service Pack 2
2. Installed the Windows Componenent Update included with Office
XP Developer
3. Installed the MS Access XP Runtime, which was created on the
development machine in the "C:\Program Files\Microsoft Office
Developer\Access Runtime\1033\ART" directory.
4. Copied a .mdb file that I verified I could open with Access XP
to the desktop of the target machine.
5. Double-clicked the .mdb file.

At this point, the Access shell popped up with nothing available inside.
Literally nothing... Basically, all I could do was close the shell. I
was doing this just to test to see if my problems were with the runtime,
which they seem to be.

My immediate problem is in my visual basic application where I instantiate
my Access.Application object. The vb project has a reference to the Microsoft
Access 10.0 Object library located in the "C:\Program Files\Microsoft

OfficeOffice10\" directory. The file MSACC.OLB has been installed and
registered

 

[George Nicholson]

Per Microsoft, there is no difference between the files installed with the
Retail and Runtime versions of Access. The difference is in registry keys
that tell the local machine which "mode" Access is licensed to run in. (You
can also force a machine with a Retail license to run in Runtime mode with a
command line switch. This is a MUST before distributing an application
intended for Runtime distribution.)

Therefore, if your application runs in retail but doesn't behave as you
would expect in runtime mode, your expectations are much more likely to be
at fault than Access. The following link may help you upgrade your
expectations

http://www.msdn.microsoft.com/library/en-us/modcore/html/detskDevelopingAcce
ssRuntimeApplications.asp?frame=true

Once you are familiar with what functionality is NOT available in Runtime
mode and have designed your app accordingly, take the Runtime issue and turn
it around: What if someone with a retail version runs this app? Make sure
you have protected everything appropriately. There is no way for you to
guarantee that it will only be run in Runtime mode, so don't take it for
granted.

Hope this helps.
Good luck

--
George Nicholson

Remove 'Junk' from return address.

After much ado, I'm coming to the conclusion that the Access XP runtime
does not work at all. I've followed the following procedures:

1. Performed clean Windows 2000 Professional installation with
Service Pack 2
2. Installed the Windows Componenent Update included with Office
XP Developer
3. Installed the MS Access XP Runtime, which was created on the
development machine in the "C:\Program Files\Microsoft Office
Developer\Access Runtime\1033\ART" directory.
4. Copied a .mdb file that I verified I could open with Access XP
to the desktop of the target machine.
5. Double-clicked the .mdb file.

At this point, the Access shell popped up with nothing available inside.
Literally nothing... Basically, all I could do was close the shell. I
was doing this just to test to see if my problems were with the runtime,
which they seem to be.

My immediate problem is in my visual basic application where I instantiate
my Access.Application object. The vb project has a reference to the Microsoft
Access 10.0 Object library located in the "C:\Program Files\Microsoft

OfficeOffice10\" directory. The file MSACC.OLB has been installed and
registered