Runtime application - no Tools menue item!

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Malcolm P - 27 Jun 2005 12:08 GMT

Problem...................................
In the original application I used AutoCorrect to add initials which when
inputted would expand into the related word/pharse. In the runtime
application, when I enter the initials the expansion works,
but................. it does not appear that I can enter new initials
because the menue item Tools / AutoCorrect is not in the runtime menue.
Question: Is there a way to add the AutoCorrect feature into the runtime
application?

Reply to this Message

Larry Linson - 28 Jun 2005 06:31 GMT

As you are finding out, there are some surprises as to what Microsoft
considers being part of "design view" and not available in the runtime. It
is for this reason that most of my clients have preferred to supply users
with full, retail access. Most security issues can be solved with Access'
security or a combination of Access' and a server DB's security.

You are not blocked from all design functionality, just from seeing design
view on-screen, so careful inclusion of function in your own forms and code
can work around many of what, at first, seem to be insurmountable barriers.
You can determine the code for many functions, and provide the limited
interface you want to present to your users in your own forms.

Larry Linson
Microsoft Access MVP

Larry Linson
Microsoft Access MVP

> Problem...................................
> In the original application I used AutoCorrect to add initials which when
[quoted text clipped - 4 lines]
> Question: Is there a way to add the AutoCorrect feature into the runtime
> application?

Reply to this Message

Malcolm P - 28 Jun 2005 12:59 GMT

I was quickly getting to that realization. My application is very dependant
on Auto/Correct and Filter-by-Form features of the full Access version;
without which the applications losses the best parts of its functionality.

Re: "supply users with full, retail access":
Who at Microsoft do I contact re this? I'm assuming that the final package
of my application, in this case, would be boxed as "The Application" and
that MS Access would just be part of it, loading along with the application.
Is this correct?

Addition question.......................
Updates. Can you start me along the path to knownledge here? What should I
be reading do learn how to update the application once distributed?

> As you are finding out, there are some surprises as to what Microsoft
> considers being part of "design view" and not available in the runtime. It
[quoted text clipped - 8 lines]
> Larry Linson
> Microsoft Access MVP

Reply to this Message

Rick Brandt - 28 Jun 2005 13:55 GMT

> I was quickly getting to that realization. My application is very
> dependant on Auto/Correct and Filter-by-Form features of the full
> Access version; without which the applications losses the best parts
> of its functionality.

What about AutoCorrect do you need them to have access to? That feature is
"Office-Wide" so even if they don't have Access they would still be able to
edit AutoCorrect entries from Word or Excel and those edits woudl be seen in
your Access app. Filter-By-Form is easy enough to replace with a strategy
called Query-By-Form. If you Google on that phrase you will get plenty of
information.

> Re: "supply users with full, retail access":
> Who at Microsoft do I contact re this? I'm assuming that the final
> package of my application, in this case, would be boxed as "The
> Application" and that MS Access would just be part of it, loading
> along with the application. Is this correct?

No, what was meant is that you tell your users that having Access installed
on their PCs is a pre-condition to using your software and have them acquire
and install it by whatever means they see fit.

> Addition question.......................
> Updates. Can you start me along the path to knownledge here? What
> should I be reading do learn how to update the application once
> distributed?

Normally you just send them a new front end file. I usually just package
this in a self-extracting ZIP file. If the back end needs changing I
usually include code in the new front end that applies the changes to the
back end file when it is first launched.

Signature

I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

Reply to this Message

Malcolm P - 28 Jun 2005 18:12 GMT

> Normally you just send them a new front end file. I usually just package
> this in a self-extracting ZIP file. If the back end needs changing I
> usually include code in the new front end that applies the changes to the
> back end file when it is first launched.

I will read up on "front end" and "back end" to find out what those terms
mean.
Will the Package Wizard that came with Access Developer Extensions work to
package the updates?

PS: Thanks for your time.

Reply to this Message

Rick Brandt - 28 Jun 2005 19:28 GMT

>> Normally you just send them a new front end file. I usually just
>> package this in a self-extracting ZIP file. If the back end needs
[quoted text clipped - 7 lines]
>
> PS: Thanks for your time.

Most professionally developed Access apps are "split" into two files. The
back end is just the tables, while the front end is everything else. More
often than not an application update only involves changes to the front end
file which is accomplished by simply replacing the older version of the file
with a new one. The packaging wizard *could* be used for this, but in most
cases it would be overkill. I would only use that if I was also needing to
include new or changed support files that needed to be registered or
installed on the target system.

Signature

I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

Reply to this Message

Larry Linson - 28 Jun 2005 23:33 GMT

> Will the Package Wizard that came with
> Access Developer Extensions work to
> package the updates?

Only in rare circumstances do Access developers send "updates" to a
database. The normal approach is to send "an updated database" and the same
Packaging and Distribution Wizard will work as well to package it as it did
for packaging the original distribution. On the other hand, if you have not
added anything that has additional dependencies (needs another supporting
.DLL, for example), you can just send the .MDE file alone, and not send all
the runtime support.

It was, in the past, possible to distribute "updates" with just enough code
to apply them to a user's database, but it is not a good practice and
introduces some security issues, as well. I have not even experimented with
it since Access 97 (and that was to confirm that an Access 95 bug had been
corrected; the only "updates" I ever distributed to users were for Access
2.0 -- the version for 16-bit Windows, which has been obsolescent and out of
support for a long while).

Back-end = tables, data, and relationships stored on a shared folder in the
network (most successful if stored on a domain server of which users are
members); Front-end = Queries, Forms, Reports, Macros, Modules, and (maybe)
Local Lookup Tables, linked to tables in the back end. Each user should have
a copy of the Front-End, and it should reside on the user's own machine (or,
if using Terminal Server, on the user's disk allocation on the Terminal
Server).

There's an introductory presentation on Access in a Multiuser Environment
that I did for my user group that you can download from
http://appdevissues.tripod.com. It will identify topics that I thought
worthwhile to discuss, and a bit more. The best collection of detailed
information and links on the subject of Access in the multiuser environment
is at MVP Tony Toews' site, http://www.granite.ab.ca/accsmstr.htm.

Larry Linson
Microsoft Access MVP

Reply to this Message