Architecture BE FE vs Network

N

NTC

Is there any logic to putting the FEs (plural) all on the BE machine - to
avoid transit time & congestion on the network for queries....

And then shortcut the users to their FE which is actually on the BE
machine....

Just thought I would put that out there for some friendly discussion.....
 
P

pietlinden

Is there any logic to putting the FEs (plural) all on the BE machine - to
avoid transit time & congestion on the network for queries....

And then shortcut the users to their FE which is actually on the BE
machine....

Just thought I would put that out there for some friendly discussion.....

What's the point of splitting the FE and BE and then sending the FE
across the network? That's the whole point of splitting - so you only
send DATA across the network, not forms etc.
 
A

a a r o n _ k e m p f

WRONG

splitting is no longer the reccomended way to do anything.

Keep your tables and queries -- where they belong-- on a database
server-- and presto-chango-- you don't need to spend your whole life
synchronizing.
 
A

a a r o n _ k e m p f

ADP is 10 times simpler-- everyone always has the correct tables and
queries--
 
T

Tony Toews [MVP]

NTC said:
Is there any logic to putting the FEs (plural) all on the BE machine - to
avoid transit time & congestion on the network for queries....

And then shortcut the users to their FE which is actually on the BE
machine....

Just thought I would put that out there for some friendly discussion.....

I did exactly that on a clients Citrix/Terminal Server system. Mind
you each user got their own copy of the FE. It might've been slightly
more sluggish but not objectionably so. So that works. But, as
others have stated, the network load would be reduced somewhat if the
FE was copied to the local system.

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's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
D

David W. Fenton

Is there any logic to putting the FEs (plural) all on the BE
machine - to avoid transit time & congestion on the network for
queries....

And then shortcut the users to their FE which is actually on the
BE machine....

You seem to be under the impression that file servers are
application servers. If you put the FE on the server, it will be
pulled across the network to the local RAM of your PC. When it
requests data, that will be pulled across the network into the local
RAM on your PC.

If you put the front end on your local PC, it won't be pulled across
the network.

So, no, there is no obvious logic in putting FEs on a file server.
The only exception is the one Tony outlined, i.e., on a Windows
Terminal Server/Citrix Server, where nothing but the Remote Desktop
Client is running in the local workstation's RAM.
 
N

ntc

Thanks all for inputs; sorry about the double post...first time the MS site
threw me an error so I didn't think it stuck;

(Am fully aware of AK's point of view.)

Consider this a light, theoretical question only....

Definitely not considering to share the FE; and understand what is being
said about a file server's role to move the FE to the desktop anyway.

I fully understand the MS recommended approach, and follow it. But it
actually was a little bit of the citrix/terminal server logic that got me
thinking about this more. If the "server" is a PC, not a file server, with
the Access license.....

so this is where I get a little fuzzy...user shortcuts to his FE on "server"
- - does that 'server' PC launch Access or does his desktop machine??....the
desktop I believe..in which case there will be the total FE mdb download to
the desktop...and beyond that no difference - - it will then operate just as
if was originally on the desktop...true?

so the net is that it is worse because it adds the initial download of the
FE but in terms of operationally there is no further change....you still end
up with the FE/BE traffic from desktop to 'server'...

in situations where that initial FE download from server to desktop isn't
burdensome - does that argue for consideration of an FE "farm" on the
'server' to ease FE update & manageablility ( a bit like citrix mgmt....)

no hostility plz.....
 
D

David W. Fenton

so this is where I get a little fuzzy...user shortcuts to his FE
on "server" - - does that 'server' PC launch Access or does his
desktop machine??

Unless you're running the app with Remote Desktop connected to a
Windows Terminal Server (or Citrix server), it is always the case
that you're running Access in the RAM of the local PC, without
exception.

Jet is not a server database engine like SQL Server. With SQL
Server, there's an application running in the RAM of your
application server that takes care of all the connections from
users, and marshalls all reads and writes to the database.

With Jet, all PCs retrieve the data from the file server, and the
file server does nothing more than what a local hard drive would do
-- it serves up the requested blocks of data.
 
J

James A. Fortune

ntc said:
so this is where I get a little fuzzy...user shortcuts to his FE on "server"
- - does that 'server' PC launch Access or does his desktop machine??....the
desktop I believe..in which case there will be the total FE mdb download to
the desktop...and beyond that no difference - - it will then operate just as
if was originally on the desktop...true?

so the net is that it is worse because it adds the initial download of the
FE but in terms of operationally there is no further change....you still end
up with the FE/BE traffic from desktop to 'server'...

I vote that "and beyond that no difference" is false. I think that the
situation is potentially much more serious. For the shared FE
situation, my guess is that a non-exclusive copy of the FE will be
downloaded to your memory, so that what someone else does using their
copy of the FE in their memory space can affect bits of the copy of the
FE in your memory space. If so, that would be a recipe for corruption,
especially if there are lots of concurrent users. Much more than locks
are being shared. You definitely want an exclusive version of the front
end, so splitting or having separate directories on something like
Citrix is much safer.

James A. Fortune
(e-mail address removed)
 
N

ntc

the shared FE is ruled out. all you say is right but the shared FE was
ruled out before.

the essence of the question at this point is FE "Farms" i.e. one per user
; kept on the BE server - - rather than putting them on the user's desktop

from all the input I believe that the impact is "only" the initial download
of the application ("only" : that could be a big impact if the FE is big and
there are alot of users)

but sub 10 users of which several are just occasional...there is a pretty
significant management advantage to avoid having to go to everyone's desktop
to install a new FE which would argue for FE Farm on the back end instead....
 
R

Rick Brandt

the shared FE is ruled out. all you say is right but the shared FE was
ruled out before.

the essence of the question at this point is FE "Farms" i.e. one per
user ; kept on the BE server - - rather than putting them on the user's
desktop

from all the input I believe that the impact is "only" the initial
download of the application ("only" : that could be a big impact if the
FE is big and there are alot of users)

but sub 10 users of which several are just occasional...there is a
pretty significant management advantage to avoid having to go to
everyone's desktop to install a new FE which would argue for FE Farm on
the back end instead....

And just what is that advantage? If you implement an automated update
mechanism to the users (something just about everyone in this scenario
does) then you put ONE updated FE on the server whenever you want.

In your scenario I have to put 10 copies of the new FE on the server in
different folders (a moving target as users come and go in the company)
and I have to do so when they are not using the app.

No big deal... I just have to phone or Email them all to exit the app and
then sit at my desk until I hear back from all of them. Oh wait, Paul
just went to lunch and left the app running. No problem, I'll just keep
trying every hour or so until I catch a time when he has the app closed.

I see no advantages in this strategy.
 
D

David W. Fenton

the essence of the question at this point is FE "Farms" i.e. one
per user ; kept on the BE server - - rather than putting them on
the user's desktop

from all the input I believe that the impact is "only" the initial
download of the application ("only" : that could be a big impact
if the FE is big and there are alot of users)

No, you're wrong -- it is *not* just the initial download. Locks
have to be maintained across the network (when your user front end
is opened there will be an LDB file created), and certain kinds of
operations save data back to the file, such as closing a form to
which a sort or filter has been applied (i.e., the sort order/filter
gets saved).

Likewise, a front end is a Jet database, and Jet always retrieves
only as much as it needs. Now, an Access front end is all stored as
part of the Access project in a single binary BLOB field in one of
the system tables, but my bet is that Microsoft has optimized the
retrieval of that data and does not retrieve all of it at once (it
*is* going to be stored in many different data pages, so,
theoretically, a map of the BLOB field at the head of the BLOB data
could be used to tell Jet how to retrieve only needed data pages).
So, you may end up with multiple trips back to the server just to
retrieve new items that have not previously been opened.

There will definitely be trips back to the server for locking (once
per second, BTW) as well as for saving sort/filters when forms are
closed.

So, again, I'd say your assumption that the performance hit occurs
only once is simply mistaken.
 
T

Tony Toews [MVP]

ntc said:
the essence of the question at this point is FE "Farms" i.e. one per user
; kept on the BE server - - rather than putting them on the user's desktop

from all the input I believe that the impact is "only" the initial download
of the application ("only" : that could be a big impact if the FE is big and
there are alot of users)

I suspect there is lots of little traffic between the place where the
FE is stored and the RAM of the PC executing the FE. Forms or
reports not previously opened may require that those objects come down
the network wire.

But when you close the object and then reopen it does it come down the
wire again? I don't know.
but sub 10 users of which several are just occasional...there is a pretty
significant management advantage to avoid having to go to everyone's desktop
to install a new FE which would argue for FE Farm on the back end instead....

That's where tools such as the Auto FE Updater come in.

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's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
N

ntc

this has been helpful;

there is inefficiencies due to the 'remote' FE approach per the input
received - - this point was not clear to me and I could not find any dialog
on this site about it...

the 'Automatic Update' obviously isn't MS's product - - so its status I
think is probably not completely appreciated or known by all users in this
community. I know that I had previously read about it but wasn't really that
familiar with it. I will definitely follow up on this.

thanks all.
 
L

Larry Linson

NTC said:
Is there any logic to putting the FEs (plural) all
on the BE machine - to avoid transit time &
congestion on the network for queries....

How would having to retrieve each query across the network from the server
to the user's machine (where all Access and Jet execution is performed)
"avoid transit time and congestion"? I don't know what assumptions you
made, but clearly they were invalid. Access with Jet or ACE is a file-server
system -- data may reside on a server, but no part of either Access or
Jet/ACE executes on the server; the file on the server is accessed they same
way it would be if it were on the local hard drive (only much, much slower).
And then shortcut the users to their FE which
is actually on the BE machine....
Immaterial.

Just thought I would put that out there for some friendly discussion.....

I see it did generate quite a bit; much of the response correct and
knowledgeable, but some of it absolutely incorrect.

For example, someone assumes that the entire Front End is transferred to the
user's machine's main memory, and no additional accesses are required, which
is patently incorrect.

Larry Linson
Microsoft Office Access MVP
 
N

ntc

the reason or benefit of the dialog is that there is a lack of clarity by
some about that point on the FE loading completely into the user's desktop if
it is being stored on the BE machine (which may be a PC). I haven't seen any
easily findable discussion of this point.

the recommended approach by MS is well understood.

but one sees frequently (at least I have) a single FE stored on the BE
machine with multiple users shortcut linked to it....and up thru A2003 it
seems to work to a degree but sometimes causes unpredictable behavior...still
alot live with it....

the change to the recommended MS approach introduces the management hassle
of having to physically be at users' desktops to implement upgrades ....so
the thought (somewhat inspired by terminal services) is whether one could
operate an FE "farm" on the BE machine....to have them all in one manageable
location.

thus the dialog on the downside of this concept; which in summary does seem
real....so the alternative is the AutoFE updater suggested....

would love to see the Auto FE updater brought to be inside the Access
product much like Link Table Manager....rather than a custom module
implementation....
 
H

hor vannara

Larry Linson said:
How would having to retrieve each query across the network from the server
to the user's machine (where all Access and Jet execution is performed)
"avoid transit time and congestion"? I don't know what assumptions you
made, but clearly they were invalid. Access with Jet or ACE is a
file-server system -- data may reside on a server, but no part of either
Access or Jet/ACE executes on the server; the file on the server is
accessed they same way it would be if it were on the local hard drive
(only much, much slower).


I see it did generate quite a bit; much of the response correct and
knowledgeable, but some of it absolutely incorrect.

For example, someone assumes that the entire Front End is transferred to
the user's machine's main memory, and no additional accesses are required,
which is patently incorrect.

Larry Linson
Microsoft Office Access MVP
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top