Access 2007 deployment and runtime question

[Cluce]

I have Access 2007. After I go through the wizard for packaging my access
project, I install it on my computer.

But when i try to run the program which uses the runtime client it is
blank(no forms, no reports, or anything) The only thing showing is the frame
of the runtime client.

The majority of my programs I package are like this.

Although, I was able to get one sample program from Microsoft(MS) packaged
and running by going through the same steps. So I tried to download another
sample database from MS to see if it was my program but the second sample
from MS didnt work either.

I am not sure what to make of this. HAs anybody seen this or know what the
problem may be?

 

[Albert D. Kallal]

Test the form on your computer BEFORE you send it out to other users.

That means you should place a shortcut on your desktop with the /runtime
switch.

When you use the runtime, you have to spend more time building the
interface, as most of it will not be present.
(on the other hand, if you going to deploy applications, then building start
up forms and a custom interface is a must do anyway).

I can't say 50% of your development budget will go into testing and making
your application work in a runtime environment, but certainly 25% of your
time budgeted can and should be dedicated to this aspect.

A shortcut with runtime will look like:

"C:\Documents and Settings\wst1\My Documents\Database1.accdb" /runtime

So, as you develop using the full version of ms-access..you can after
building a form, or making changes, exit the appcation, and then click on
your "runtime" shortcut to see how the application will function as runtime.
You likely do this development dance of exiting and testing as runtime all
day long...

So, try running and testing on your machine as runtime.

As mentioned, you need to setup the startup options to run a form for ht
user. You have to MUCH think of developing here in mind that the end user
does not know ms-access, and obviously will not have purchased ms-access
either (so, you likely not only provide some nice forms but also building a
custom ribbons for the application is a very good idea also).

 

[Cluce]

Thanks for the reply. I aware I need to develop the interface which I am
doing in VB but for some reason my program will ONLY run in with the full
version of Access.
I tried to do the shortcut target but that doesn't show anything either. I
am trying to figure out why I get nothing(no forms, no buttons, textboxes,
controls or anything). The only thing that shows up is the frame of the
runtime client.
Oh, it just hit me. Maybe I need to do a Macro for the form to show up? I
will check into this.

 

[Albert D. Kallal]

Thanks for the reply. I aware I need to develop the interface which I am
doing in VB but for some reason my program will ONLY run in with the full
version of Access.
I tried to do the shortcut target but that doesn't show anything either.

Exactly, so your telling me that with the runtime shortcut, you see nothing.
This proves that
it not the other machine, but in fact your setup is wrong. You have to setup
your
application to launch and run a form.

am trying to figure out why I get nothing(no forms, no buttons, textboxes,
controls or anything). The only thing that shows up is the frame of the
runtime client.
Oh, it just hit me. Maybe I need to do a Macro for the form to show up? I
will check into this.

As I mentioned, you need to set the startup form that launches
(you have to make the software run for the user...I mean how
can they know what form they are supposed to run????

So, go into the startup options, and setup a form to launch when the
application starts.
(office button->access options (lower right)--> current database).

The options to complete hide and keep people out of the ms-access interface
can
easily be done using the tools->start-up options. Using those options allows
you to
complete hide the ms-access interface (tool bars, database window etc).
You don't really need to test with the "runtime" switch if you setup this up
correctly.

How much of a custom interface you built already will dictate how much work
it
will be to make your application run smooth as runtime.

Of course, during development, you will hold down the shift key so your
startup settings don't run. You then develop for awhile, and then to test in
"user" mode, you exit..and then re-enter the application without the shift
key bypassed. You will likely do this dance all day long as you run/test as
user mode, and then flip back in to developer mode (shift key used..so you
don't get the main custom menu). So, you can't develop, or really modify
things when you run your application with the startup settings...so you must
shift-by-pass them when you want to work.

And, in fact, I use alt-f4 to exit the application...the mdb file should
still be highlighted in the windows explore..so, then you hit enter key
(and, hold down shift key if you need be). This key stroke sequence and
exiting and re-entering the application will occur CONSTANTLY all day long
when you are developing.

When you finally have things just right...you create the mde
you plan to distribute...

(or, in a2007, a accDE)

 

[George Nicholson]

Forms don't open by themselves.

Forms are not psyhic. You need to either specify a Startup form or have an
AutoExec macro that will (directly or indirectly) open a form.

 

[Cluce]

Thanks for the feedback. Well, I have vb.net programming experience which by
default the first form developed in the project is the startup form without
having to set it to start up. But I am getting the hang of it now.