Menu Bars in MS Access on Terminal Server

[Mike Clinton]

I have an Access 2000 application with several custom menu bars
associated with various forms.

When this application is run in a Terminal Server or Remote Access
session the correct menu bars do not always immediately display.
Sometimes the previous form's menu bar remains there, sometimes a
blank menu bar, and sometimes two menu bars.

If a user clicks in the menu bar area the correct menu bar does then
display.

But sometimes the user is unfortunate enough to try to close the form
by clicking the Close button that should be there at the top right. If
the menu bar has not appeared the user may mistakenly click the
application Close button, and inadvertantly exit the application (and,
in this case, the remote session).

I've been looking for a solution for many months now...

Can anything be done to make menu bars display properly in MS Access
apps on a Terminal Server?

Is anyone at Microsoft listening?

Mike

 

[Stephen J. Levine MD]

How are you associating the menubars with the forms? Are
you just doing it statically by specifying the menubar on
the forms property page in design view. Or are you
trying to do it programmatically in VBA? In some
situations, doing it programmatically may mean that it
does not become active until the form is closed and then
opened again.

I am working out issues with menubars since I am trying
to make the menubar selected dependent on the security
setup of the user. But that is another story, of which I
think I have a solution, but have not had a chance to try
yet.

Menubars 'R' Us
sjl

 

[Albert D. Kallal]

Does the same behaviour occur when you run the software on that sever. I.e.,
log on as a user and NOT use TS?

I have not seen any posts here mention the problem of menu bars not working
with TS. Further, TS is rather reliable, and VERY good a displaying the
screen.

Perhaps, this is simply a problem with your application?

If your problem was known, then there would be knowledge base articles, bug
reports,a and even just general posts in the newsgroups about people having
this problem. Since I see no re occurring issue or even articles on this,
then I would have to first look at the install, or setup you have.

Also, are you running a split database? (you should be). Also, does each
user who logs on get their own front end? Allowing multi-users into the same
front end that is trying to hide/display menu bars is not a good idea at
all.

So, assuming the basic CORRECT setup that any developer would use (ie: split
database, each user gets their OWN front end), then I would log on to the
physical server, and do some testing that way to "eliminate" the fact of TS.

I don't think this is TS problem at all. However, you don't mention what
version of ms-access. You probably should be using a mde for each users
front end. Remember, even when using TS, EACH USER STILL MUST GET THEIR OWN
copy of the front end. Using TS does not get you off the hook of following
the basic correct setup that any developer worth their salt will use. That
setup should be no different then the fact that humans breath air.

The advice to run a split database is given out on a daily basis in this ng.

 

[Rick Brandt]

Does the same behaviour occur when you run the software on that sever. I.e.,
log on as a user and NOT use TS?

I have not seen any posts here mention the problem of menu bars not working
with TS. Further, TS is rather reliable, and VERY good a displaying the
screen.

Perhaps, this is simply a problem with your application?

The only thing similar I have seen (pretty frequently) is that the toolbar
assigned to a Report will not initially display until you click on the report in
preview mode to change the zoom and then the toolbar shows up. I have lots of
users report this and have seen it myself when using Access locally (no Terminal
Server). You could be seeing something similar. I have always assumed it was
a screen update / memory issue so perhaps TS can aggravate that and make it more
prevalent.

 

[Stephen J. Levine, MD]

Alber

I have real difficulty with the concept of giving each user their own MDE front end, in that it complicates version control. What I have done with an Access Application I just wrote is to have a central MDE with shortcuts from each users desk. The database is split with the data tables in a separate MDB file. Basically, all users have the same database property settings, which are programmatically set with each use via an autoexec macro running a VBA function. All dynamic information unique to each session is handled thru variables, including arrays, defined within VBA modules. I use pessimistic record locking, supplemented with a check out field that, when populated, prevents other users from accessing the same master and subsidiary records. I would have preferred to have used Access only as a front end for Oracle, which I use a lot, but data security issues relating to Oracle ODBC drivers made me wary of doing this. I do plan to go back in the future and, perhaps, put the tables in Oracle, maybe via Ole-DB linkage (which I need to learn how to do)

I am developing a report menuing system for this application outside of the application itself and have been reading your advice regarding the use of different menubars for different users (basically, if I understand you correctly, you are saying DON'T). Based on your advice, I am scrapping plans to tie menubars into security and instead will control it another way.

sj

 

[Rick Brandt]

Albert

I have real difficulty with the concept of giving each user their own MDE

front end, in that it complicates version control. [snip]

I would argue that it simplifies version control. When you have an
automated system for update notification and installation (not very hard to
do BTW) each user is then always running the latest version simply by
getting an update each time they launch the application. With everyone in
a single file you have to notify all users (at the same time) so you can
get them all out of the file (at the same time) and those bozos who left
the app running when the went to lunch mean you either have to wait or use
a non-elegant solution to boot them out.

 

[Albert D. Kallal]

There is a old saying about leading a horse to water, but can you make it
drink!

There is not one access developer worth their salt on the planet earth that
will tell to run anything but a split mdb, and that EACH USER gets their own
front end.

I not going to argue here about what is a good and sensible practice. In
fact, if you bring me in as a consultant, I will state that the previous
people who setup the database did it incorrectly. In fact, I would actually
suggest that a refund be requested for much of the work, as the people
involved before me not competent.

Even when you run the best setup, things can still go wrong. I only
suggesting that you run the best setup you can.

Hence, why not run things to the best of your abilities?

From a maintains point of view, and also from a reliability point of view,
each user should have their own front end. It is simply the way ms-access
works.

You can cobble together some code to check for new front end updates. (took
me about 1 hour to write such code). However, Tony has nice updater for
free, and it even works with TS.

Check out:
http://www.granite.ab.ca/access/autofe.htm

I use pessimistic record locking, supplemented with a check out field that,

when populated, prevents other users from accessing the same master and
subsidiary records.

Interesting, but I did a number of years ago write my own locking routines.
Since my locking routines prevent more then one user on the same "master
form", then I was able to leave the locking in ms-access alone
(opportunistic locking). And, you clearly point out that the child records
are safe, since you have to go through the "master" form. You can read about
that locking approach of mine in this message. Pay close attention to the
criteria I set for the locking:

http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=47300
&ixReplies=7

I am developing a report menuing system for this application outside of

the application itself and have been reading your advice regarding the use
of different menubars for different users (basically, if I understand you
correctly, you are saying DON'T). Based on your advice, I am scrapping
plans to tie menubars into security and instead will control it another way.

Gee, again, we kind of work with the limitations of the product. I certainly
understand your desire to have different menu bars, but all in all there is
going to be some coding hassles with this approach. By simply specifying the
menu bar in the "other" tab, then you reduce coding time and cost. I would
also say that I don't know of very many applications that "change" the menu
bars on the users. When you change the menu bars, then things like training
manuals are more difficult to write. You also can confuse the users when you
change security settings also. I seen users scream when the new version of
word comes out and a menu option was simply moved!

You also have to remember that if you some maintains form, or whatever that
is restricted to some uses, since users can't launch the form, then they
will not get that menu associated with the form anyway.

In the case of particular menu options, you have code check the security
group anyway,a and I just give the user a message that they don't have
permissions. Speaking of permissions, I never did like the built-in user
interface, so I built my own. You can read about it here:

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

 

[cabong]

*I have real difficulty with the concept of giving each user their
own MDE front end, in that it complicates version control. What I
have done with an Access Application I just wrote is to have a
central MDE with shortcuts from each users desk.*

There seems to be a consensus for a workstation setup but I too find
that managing files can get time consuming. Also we have purchased some
"commercial" application in the past (mostly T&B related), and we were
also told to run the front end locally.

What's wrong with setting up \runtime shortcuts locally instead?

keep it coming guys, very interesting.

On topic:
Are u having the same problem with other TS application? Are u setting
up your bar through VBA code? Perhaps TS refresh rate?
I don't know, just guessing here. More info would help.

 

[cabong]

On a side note this is a great page you got there. Definitely one to b
bookmarked. Good work and thanx for the precision on FE-BE

 

[Guest]

The practice in our field is to have very infrequent
updates and also go through extensive user validation
with each. Consequently, these updates will have a large
number of changes with them.

For example, the vendor of our primary business system
only provides updates twice a year.

In this sort of environment, it is not hard to make the
update installation a formal organization-wide event
occurring at a predetermined time, and thus get users off
of the software while you are updating.

I might add, that in the business I am in, process
control is a requirement and this includes software
control.

sjl