Terminal Server or runtime version?

[Paul H]

I have been approached by a new customer to "sort-out" their existing
database. They occasionally need to remotely access the database and are
using Terminal Server to do so. The weird thing is that all of the local
users are using TS as well to save on Access licences!

Two questions:

If 20 people use TS to access a database do you need an Access licence for
each user?

Is there a big difference in performance between these two set-ups:

1. Frontend and Backend both installed on a Terminal Server.
2. Frontend installed on Workstation (with Access runtime) Backend installed
on server.

The database has around 20 users (5, maybe 10 concurrent) light usage,
fairly straight forward crm system.

Thanks,

Paul

[Rick Brandt]

Paul H wrote:

I have been approached by a new customer to "sort-out" their existing
database. They occasionally need to remotely access the database and
are using Terminal Server to do so. The weird thing is that all of
the local users are using TS as well to save on Access licences!

Two questions:

If 20 people use TS to access a database do you need an Access
licence for each user?

Unless they are using the runtime on the TS then they are violating the
EULA. TS does not equal "free software".

Is there a big difference in performance between these two set-ups:

1. Frontend and Backend both installed on a Terminal Server.
2. Frontend installed on Workstation (with Access runtime) Backend
installed on server.

On a LAN, no. On a WAN the first is the only option that is practical at
all.
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[Tony Toews [MVP]]

"Paul H" <pa**@nospam.co mwrote:

>Is there a big difference in performance between these two set-ups:

1. Frontend and Backend both installed on a Terminal Server.
2. Frontend installed on Workstation (with Access runtime) Backend installed
on server.

Option 1 would be substantially faster. As much as five times faster.

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

[Jan]

Can I just clarify on this....even when both parts are on the Terminal
Server, each user should still have their own copy of the front end,
right? I"m trying to set this up for the first time for a client and
I'm still struggling with how to do a "generic" front-end setup.

Thanks.

Jan

Tony Toews [MVP] wrote:

"Paul H" <pa**@nospam.co mwrote:

>Is there a big difference in performance between these two set-ups:
1. Frontend and Backend both installed on a Terminal Server. 2.
Frontend installed on Workstation (with Access runtime) Backend
installed on server.

Option 1 would be substantially faster. As much as five times
faster.

Tony

[Tony Toews [MVP]]

Jan <ja*@dontspamme .comwrote:

>Can I just clarify on this....even when both parts are on the Terminal
Server, each user should still have their own copy of the front end,
right? I"m trying to set this up for the first time for a client and
I'm still struggling with how to do a "generic" front-end setup.

Yes, even when on TS each user should have their own copy of the FE.

1) Sharing an FE is prone to corruptions of the FE.

2) To update the FE MDB/MDE means you have to kick everyone out.

3) 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

[Jan]

Hi, Tony:

Thanks for answering. I know all about not sharing the FE, and I have a
system I use (not yours; an old one from Danny Lesandrini) to do the
automatic updating. I just haven't figured out how to do it in a TS
environment, mainly because the one I use expects the FE to always be in a
particular named folder on a particular-named path, and with the TS that
doesn't seem to be the case. I just have to find the time to figure it out.

I will indeed look again at your utility; any further hints would be
welcome.

Jan

Tony Toews [MVP] wrote:

Jan <ja*@dontspamme .comwrote:

>Can I just clarify on this....even when both parts are on the
Terminal Server, each user should still have their own copy of the
front end, right? I"m trying to set this up for the first time
for a client and I'm still struggling with how to do a "generic"
front-end setup.

Yes, even when on TS each user should have their own copy of the FE.

1) Sharing an FE is prone to corruptions of the FE.

2) To update the FE MDB/MDE means you have to kick everyone out.

3) 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

[Paul H]

"Tony Toews [MVP]" <tt****@teluspl anet.netwrote in message
news:q2******** *************** *********@4ax.c om...

Jan <ja*@dontspamme .comwrote:

>>Can I just clarify on this....even when both parts are on the Terminal
Server, each user should still have their own copy of the front end,
right? I"m trying to set this up for the first time for a client and
I'm still struggling with how to do a "generic" front-end setup.

Yes, even when on TS each user should have their own copy of the FE.

1) Sharing an FE is prone to corruptions of the FE.

2) To update the FE MDB/MDE means you have to kick everyone out.

3) 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

Tony,

Just to clarify even further.. :O)

Should the TS folders be set up like this:

UserA_DB_FE_Fol der - has a copy of the FE in it
UserB_DB_FE_Fol der - has another copy of the FE in it
UserC_DB_FE_Fol der - has another copy of the FE in it
DB_Backend_Fold er - has the backend in it

Eac user only has permissions to his own FE folder plus the BE folder.

And as long as the TS has enough horsepower will this always be quicker than
each client having a FE stored locally? Doesn't it depend on the database:
If the database FE tends to pull a lot of data, TS would seem the best
option, but if the FE database spent more time talking to other apps or was
just more heavy on CPU usage would it not be best to have the FE stored
locally on the client?

Thanks

Paul

[David W. Fenton]

Jan <ja*@dontspamme .comwrote in
news:13******** *****@corp.supe rnews.com:

I just haven't figured out how to do it in a TS
environment, mainly because the one I use expects the FE to always
be in a particular named folder on a particular-named path, and
with the TS that doesn't seem to be the case. I just have to find
the time to figure it out.

You can make a folder in the user profile. To find that, you can use
the code here:

http://www.mvps.org/access/api/api0054.htm

to find the location.

Or you can assume it's C:\Documents and Settings\%USERN AME% and just
construct it from the logged-on username. There's even an
environment variable for it, though that can be unreliable (as it
could be changed by the user).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

"Paul H" <pa**@nospam.co mwrote in
news:E9******** *************** *******@eclipse .net.uk:

Should the TS folders be set up like this:

UserA_DB_FE_Fol der - has a copy of the FE in it
UserB_DB_FE_Fol der - has another copy of the FE in it
UserC_DB_FE_Fol der - has another copy of the FE in it
DB_Backend_Fold er - has the backend in it

Eac user only has permissions to his own FE folder plus the BE
folder.

And as long as the TS has enough horsepower will this always be
quicker than each client having a FE stored locally? Doesn't it
depend on the database: If the database FE tends to pull a lot of
data, TS would seem the best option, but if the FE database spent
more time talking to other apps or was just more heavy on CPU
usage would it not be best to have the FE stored locally on the
client?

You can't run Access across a WAN unless it's been very carefully
designed to work in that environment and it's not recommended.

Running on TS eliminates all the work of re-architecting your app to
run over a WAN, and puts all the administration in one place (you
don't have to worry about installing Access on multiple
workstations, and keeping them healthy, and installing the front end
and so forth).

If your TS front end needs to talk to programs on the workstation,
then that's a problem. I can't think of a circumstance in which that
would be advisable. Do you have an example?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Jan]

Thanks, David.

I tried it with C:\Documents and Settings\%USERN AME% once and it failed,
I think with an error that implied it wasn't getting "Documents and
Settings" as one folder name (you know, that error that says "can't find
folder c:\documents"). At that moment I was swamped with other stuff
and put it aside. Now I'll have to go back and really pursue it.

BTW, does the %USERNAME% have to be in all caps?

Jan

David W. Fenton wrote:

Jan <ja*@dontspamme .comwrote in
news:13******** *****@corp.supe rnews.com:

>I just haven't figured out how to do it in a TS environment, mainly
because the one I use expects the FE to always be in a particular
named folder on a particular-named path, and with the TS that
doesn't seem to be the case. I just have to find the time to
figure it out.

You can make a folder in the user profile. To find that, you can use
the code here:

http://www.mvps.org/access/api/api0054.htm

to find the location.

Or you can assume it's C:\Documents and Settings\%USERN AME% and just
construct it from the logged-on username. There's even an environment
variable for it, though that can be unreliable (as it could be
changed by the user).