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.comwrote:

>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.comwrote:

>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****@telusplanet.netwrote in message
news:q2********************************@4ax.com...

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_Folder - has a copy of the FE in it
UserB_DB_FE_Folder - has another copy of the FE in it
UserC_DB_FE_Folder - has another copy of the FE in it
DB_Backend_Folder - 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.supernews.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\%USERNAME% 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.comwrote in
news:E9******************************@eclipse.net. uk:

Should the TS folders be set up like this:

UserA_DB_FE_Folder - has a copy of the FE in it
UserB_DB_FE_Folder - has another copy of the FE in it
UserC_DB_FE_Folder - has another copy of the FE in it
DB_Backend_Folder - 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\%USERNAME% 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.supernews.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\%USERNAME% 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).

[Paul H]

"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...

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

>Should the TS folders be set up like this:

UserA_DB_FE_Folder - has a copy of the FE in it
UserB_DB_FE_Folder - has another copy of the FE in it
UserC_DB_FE_Folder - has another copy of the FE in it
DB_Backend_Folder - 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/

Sorry David, I got my wires crossed. I thought we were talking about a LAN
environment only. (I do understand that Access is designed for LAN use).
Which is why I questioned the idea the TS will "always" give better
performance than placing the FE on the workstation.

I think I worded the initial post badly, what I meant to ask was:

All users are on a LAN, they have a single frontend in the same folder as
the backend (on the server). All of them use TS to open the same FE file.
Should we scrap TS for Access and put a FE on each client?

Paul

[David W. Fenton]

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

I tried it with C:\Documents and Settings\%USERNAME% 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.

Did you surround "C:\Documents and Settings\%USERNAME%" in double
quotes, just like I did? Anytime there's a space in a path or
filename, you have to do that (this is why I never use spaces in
paths or filenames).

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

Nope.

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

[David W. Fenton]

"Paul H" <pa**@nospam.comwrote in
news:oe******************************@eclipse.net. uk:

All users are on a LAN, they have a single frontend in the same
folder as the backend (on the server). All of them use TS to open
the same FE file. Should we scrap TS for Access and put a FE on
each client?

There is no situation, whether involving TS or not, whether
involving a WAN or a LAN where more than one user at a time should
be opening any front end. Period. That's an ironclad principle.

If they are on a LAN you can still have them run on TS and there is
justification for doing so:

1. they don't have to have the exact version of Access installed on
their workstations (though newer versions of Office likely enforce
this differently than past versions, which seem to be very forgiving
on this point).

2. you don't have to administer setups on workstations. There are
two parts to that: the front end and the Access installation. Access
can get out of whack and cause problems (such as reverting to
release versions when a machine is rebuilt).

On a TS, all your administration is centrally located, and that's a
huge advantage.

But without question, each user needs an individual copy of the
front end, no exceptions.

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

[Paul H]

"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...

"Paul H" <pa**@nospam.comwrote in
news:oe******************************@eclipse.net. uk:

>All users are on a LAN, they have a single frontend in the same
folder as the backend (on the server). All of them use TS to open
the same FE file. Should we scrap TS for Access and put a FE on
each client?

There is no situation, whether involving TS or not, whether
involving a WAN or a LAN where more than one user at a time should
be opening any front end. Period. That's an ironclad principle.

If they are on a LAN you can still have them run on TS and there is
justification for doing so:

1. they don't have to have the exact version of Access installed on
their workstations (though newer versions of Office likely enforce
this differently than past versions, which seem to be very forgiving
on this point).

2. you don't have to administer setups on workstations. There are
two parts to that: the front end and the Access installation. Access
can get out of whack and cause problems (such as reverting to
release versions when a machine is rebuilt).

On a TS, all your administration is centrally located, and that's a
huge advantage.

But without question, each user needs an individual copy of the
front end, no exceptions.

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

Thanks David,

One more thing. Do I need I an Access licence for every PC that uses an
Access database via TS? If so, could I put the Access runtime on TS?

Thanks,

Paul

[David W. Fenton]

"Paul H" <pa**@nospam.comwrote in
news:uo******************************@eclipse.net. uk:

One more thing. Do I need I an Access licence for every PC that
uses an Access database via TS? If so, could I put the Access
runtime on TS?

It depends on the version of Access. I have never actually run an
Access app on TS without having full Office Pro installed on all the
workstations that connect, so I'm not certain what happens. I do
know that I often run A2K3 on TS from my own workstation, and only
have A2K and A2K2 installed.

The runtime would obviate any issue with that at all.

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