Odd behavior Access 2002 on Terminal Server

[Guest]

I have developed an Access 2002 database that resides on a Terminal Server.
All users sign in to the Terminal Server and open the database via an icon on
their desktop.

There are time when a user will tab/enter thru the fields and get to a field
and the form "freezes" - not allowing them to move to another field or exit
the screen. I, on the other hand, never have this problem and can only
recreate it if I go to the user's desktop.

Any ideas?

 

[Joshua A. Booker]

Dawn,

On a Terminal Server, it is recommended that all users open their own copy
of the database front-end having linked tables to the shared back-end. Is
this the setup you are using?

HTH,
Josh

 

[Guest]

No the database is all in one mdb.

I understand the concepts of splitting a database. But what would that
accomplish with this problem?

THANKS!

 

[Joshua A. Booker]

Hi Dawn,

It would change your setup to a 'supported' configuration for one thing.
And limiting the mdb to one user would remove a layer of complexity from a
problem that appears user login related.

Hard to say if this would fix the problem, but I've certainly seen stranger
behaviour while sharing an mdb on TS go away after splitting.

So that's where I'd start. Just a suggestion.

P.S...You will likely have data corruptions on TS if you don't split the
mdb.

HTH,
Josh

 

[Guest]

Thanks Josh,

What do you mean by: "limiting the mdb to one user"? All users signon as
themselves to the terminal server and the db as we need to track changes.

My other concern about splitting the db at this time is that we are in
development/production mode where every week I install new functionality or
mods. This would require a new front end for each user (30+) every week?

Thanks for your help!

 

[aaron.kempf]

Dawn

the con-artist that convinced you to run Access across a terminal
server should be in prison.

terminal is overkill; it defeats the purpose of the PC revolution.

Using the resources of the client and the server-- for example an ADP
you have much much better performance.

Lose the training wheels; MDB has been obsolete for a decade.

ADP is the way to go.

 

[aaron.kempf]

Splitting is overly complex.

Use ADP. you can change sprocs in one place using ADP and you don't
need to deal with _ANY_ of this 'auto fe updater' crap

if you need to change a table or a query you can do that while people
have it open *( if you have permissions)

-Aaron

 

[Tony Toews [MVP]]

What do you mean by: "limiting the mdb to one user"? All users signon as
themselves to the terminal server and the db as we need to track changes.

Give each user their own MDB.

My other concern about splitting the db at this time is that we are in
development/production mode where every week I install new functionality or
mods. This would require a new front end for each user (30+) every week?

However you really want to put the FE on each machine or place in a
user specific directory on the server. This will help avoid some
weird error messages when users are changing the same forms record
source, filters and such as well as corruptions. It is also much
easier to implement a new version of the database with changed
queries, forms, reports and VBA code.

I specifically created the Auto FE Updater utility so that I could
make changes to the FE MDE as often as I wanted and be quite confident
that the next time someone went to run the app that it would pull in
the latest version. For more info on the errors or the Auto FE
Updater utility see the free Auto FE Updater utility at
http://www.granite.ab.ca/access/autofe.htm at my website to keep the
FE on each PC up to date.

In a Terminal Server or Citrix environment the Auto FE Updater now
supports creating a directory named after the user on a server. Given
a choice put the FE on the Citrix server to reduce network traffic and
to avoid having to load objects over the network which can be somewhat
sluggish.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Joshua A. Booker]

Dawn,

After splitting the mdb, each user will get their own copy of the front-end.
Each front-end mdb/mde will be 'limited to one user'.

In my experience, we're always in both development and production mode.
That's the nice thing about Access as a rapid dev environment.

The best thing to do is to setup logon scripts that copy the front-end to a
user's profile directory at logon. If it's a large file or you have many
users, it's good to use a logoff script to delete it when they logoff. That
way you don't fill the hard drive with files for users that are not even
logged in.

You can setup these scripts in either local (on TS machine) or domain (in
active directory) Group Policy Objects.

With scripts doing the deployment work:
You can update and test on a single design version of the application
You can deploy the changes as either mdb or mde to a single production file
The production file gets copied to the user profile directory at login
You will never have to close users out to make changes...just ask them to
login again to get the update.

Hint: You can use the %UserProfile% system variable to setup a singe
shortcut in the 'All Users/Desktop' directory to display the same shortcut
for every TS user. Or you can use %UserProfile% in the 'start this
application' of their TS settings if you don't want them to get a desktop at
all. This will just open the database automatically after login.

HTH,
Josh

 

[Tony Toews [MVP]]

The best thing to do is to setup logon scripts that copy the front-end to a
user's profile directory at logon.

Best? Not necessarily. It is an option but can have problems. For
example if they are on the end of a WAN connection for some unknown
reason this could take a considerable length of time. A friend was
logging onto a system a thousand miles from home on a WAN. As he was
muttering about why it was taking him so long to log on he realized
that he had a bunch of zip files on his desktop.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Tony Toews [MVP]]

The best thing to do is to setup logon scripts that copy the front-end to a
user's profile directory at logon.

Oh yes, and for this you might have to get IT involved. <shudder>

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Joshua A. Booker]

Tony,

You're right...I have to be carefull not to use absolute language such as
the term 'best'

I'm not familliar with Citrix, but assuming we're talking about a user
logging into a windows terminal server, I don't see how a slow WAN has much
to do with the length of time it takes the terminal server to copy a file
from one directory to another on the TS machine.

I would certainly not recommend copying a file to the client machine over a
WAN and don't understand why that would apply to a TS environment...does
Citrix do that?

Josh

 

[aaron.kempf]

Tony;

Access Data projects never have a bloat problem

keep all your tables and queries where they belong-- in SQL Server

sprocs are 100 times more powerful than MDB; lose the training wheels,
kid

 

[aaron.kempf]

Tony;

maybe if you weren't such an 'access pussy' then maybe IT wouldn't
give you a hard time.

I have never had trouble with IT.

it's because I don't ask them to go in and compact and repair a
database by hand once a month LOL

-Aaron

 

[Tony Toews [MVP]]

You're right...I have to be carefull not to use absolute language such as
the term 'best'

I'm not familliar with Citrix, but assuming we're talking about a user
logging into a windows terminal server,

Citrix runs on top of Terminal Server and has a lot of added
functionality.

I don't see how a slow WAN has much
to do with the length of time it takes the terminal server to copy a file
from one directory to another on the TS machine.

On the TS machine you are correct. My other posting was for someone
logging onto a system on a WAN.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm