Access 2003 Run-Time / Dev Extensions ?

[Sally Green]

Hi, I have had no experience with the Run Time version of Access. I have
writen a database for a client who has multiple users. To reduce the costs
of licensing only some of their users have the full version of Access, the
rest have this Run-Time version. The database only works for the users with
the full version.

Is there anything I can do to compile the database so that is works across
all versions, or does my client have to bite the bullet and upgrade all their
users?

I don't know anything about Developer Extension? Just read this in another
post.

Thanks
Sally

 

[Rick Brandt]

Hi, I have had no experience with the Run Time version of Access. I
have writen a database for a client who has multiple users. To
reduce the costs of licensing only some of their users have the full
version of Access, the rest have this Run-Time version. The database
only works for the users with the full version.

Is there anything I can do to compile the database so that is works
across all versions, or does my client have to bite the bullet and
upgrade all their users?

I don't know anything about Developer Extension? Just read this in
another post.

There are only a handful of features not supported in the runtime. For
example Filter-By-Form is not. None of these though are "deal breakers" so
your app should (for the most part) work in the runtime if it works in
regular Access with one caveat...

There is almost no inclusion of the standard Access interface in the
runtime. It is intended to be used with fully polished, mature
applications. You must replace ALL menus and toolbars with custom ones that
you create (including shortcut menus). You must designate a startup menu
form or menu bar for the user to navigate around in the app because the db
window is not available in the runtime. Failure to do this step means a
blank gray window when the file is opened with no capability to do anything.

Other than that you would have to supply mores specifics about what you mean
when you say it doesn't work.

 

[Sally Green]

Thanks Rick for your reply. That's shed a bit of light on it for me. The
database wasn't developed with using Access Run-Time and so I guess they are
lucky that it opens and they can do some things in it. It does have a Mian
Menu (a Switchboard). It has a lot of vba code behind the forms. It opens
with a Userform so they can log in and depending of their user id it assigns
a security level to that use which determines what that user can do in each
form. Ie some users can delete a record, soem can add a new record, some can
edit a record. Various different check boxes appear at different stages i
nthe data entry forms depending on their security level. These don't appear
in the run-time version and delete, add, edit is not prevented. Which leads
me to believe that some of the code doesn't run.

On one particular form they have to enter a date and it does then filter by
that date to list all transactions made on that date. So following your
reply I understand now why that aspect doesn't work.

Many years ago in Access 2.0 you could buy a Developers Kit and 'compile' a
database so that it could be run on a computer that didn't have Access
installed. Is this still available in these later versions?

Thanks for your help, I think the Microsoft Newsgroup is fantastic and I'm
always appreciative of the time you guys must spend painsakingly replying to
us all. Well done on an excellent service!

 

[Rick Brandt]

Thanks Rick for your reply. That's shed a bit of light on it for me.
The database wasn't developed with using Access Run-Time and so I
guess they are lucky that it opens and they can do some things in it.
It does have a Mian Menu (a Switchboard). It has a lot of vba code
behind the forms. It opens with a Userform so they can log in and
depending of their user id it assigns a security level to that use
which determines what that user can do in each form. Ie some users
can delete a record, soem can add a new record, some can edit a
record. Various different check boxes appear at different stages i
nthe data entry forms depending on their security level. These don't
appear in the run-time version and delete, add, edit is not
prevented. Which leads me to believe that some of the code doesn't
run.

Unless the code tries to make permanent design changes to forms or reports
(open them in design view) there is nothign about the runtime that should
make it not work.

There is an issue with library references that can make code in an app not
work on one PC while it works fine on another. You could be seeing that and
the runtime is not the issue at all.

On one particular form they have to enter a date and it does then
filter by that date to list all transactions made on that date. So
following your reply I understand now why that aspect doesn't work.

It is only the specific tool named "filter by form" that doesn't work in the
runtime. You can certainly apply filters to forms by other means (including
code).

Many years ago in Access 2.0 you could buy a Developers Kit and
'compile' a database so that it could be run on a computer that
didn't have Access installed. Is this still available in these later
versions?

That was just the runtime for Access 2. You could never compile an Access
file into a stand-alone executable.