FE BE architecture vs Network

[NTC]

Is there any logic to put the FE (s - plural) on the same machine as the BE;
so that the data does not transit the network...

and shortcut/map the user to their FE which is on the backend machine...

Have been mulling that architecture ideal for awhile.....sure would assist
distribution of new FEs by not having to go to everyone's desktop, although
am thinking more in terms of avoiding network transit time to load tables to
the desktops.........

Clearly that BE machine is doing alot more calcs but....

Just thought I would throw that out for some friendly discussion......

 

[Norman Yuan]

Placing FEs and BE on the same machine does not reduce data trnsit in the
network. The FE has to be loaded intoll users' computer's memoery, where
Access or access runtime is installed, to run, so data in BE still have to
go to users computer back and forth. Not to mention the known problems of
sharing a FE file.

 

[pietlinden]

Is there any logic to put the FE (s - plural) on the same machine as the BE;
so that the data does not transit the network...

and shortcut/map the user to their FE which is on the backend machine...

Have been mulling that architecture ideal for awhile.....sure would assist
distribution of new FEs by not having to go to everyone's desktop, although
am thinking more in terms of avoiding network transit time to load tablesto
the desktops.........

Clearly that BE machine is doing alot more calcs but....

Just thought I would throw that out for some friendly discussion......

What about using AutoFE Updater from here....
http://www.granite.ab.ca/access/autofe/why.htm

(along with some reasons why to split...)

 

[John Spencer]

Actually, that will increase network traffic, not decrease it. All the
forms, etc will have to load across the network and then any data
processing will involve network traffic also.

Think of it this way. The data (BE) and application (FE) are going to
be handled the same way by your computer. If they are both on the local
hard drive then no network traffic is involved. If they are both on a
server then everything gets processed the same as if they are both on
the local hard drive but with a very long cable to get to the information.

'====================================================
John Spencer
Access MVP 2002-2005, 2007-2008
The Hilltop Institute
University of Maryland Baltimore County
'====================================================

 

[Tony Toews [MVP]]

Is there any logic to put the FE (s - plural) on the same machine as the BE;
so that the data does not transit the network...

Trouble is what you are missing is that the various objects in the FE
have to be loaded in the memory of the client PC. Conceivably the
same object might be copied across the network multiple times
depending on how well Access works this way.

Now the ideal solution would be a Terminal Server/Citrix solution with
the FEs and the BE installed on the systems hard drive. No network
traffic at all. Now that'd be like working on the database on your
own 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/

 

[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.....

 

[Rick Brandt]

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?

No. An Access file is not a "document" that is loaded completely into
memory. Bit and pieces will be pulled over as you are using the file.
Also bits and pieces will be written back to the server's disk while you
are using it.

So...userA pulls in a bit, saves back a bit. While that is going on
userB is doing the same thing. A bit of userA's write to disk steps on
the bit userB is writing to disk and there you go; conflict or corruption.

 

[ntc]

hmm...now... even if they have separate FEs?

I wouldn't have thought so...the data still comes together in the BE only.

But what you say about the remote FE not fully loading into the desktop
machine is of interest...because this is where I am fuzzy...

just theoretical interest....

 

[Rick Brandt]

hmm...now... even if they have separate FEs?

Okay I missed that while stored on the server that they were still
separate. In that case you would only suffer some performance drag of
having the file on the server instead of local.

 

[David W. Fenton]

So...userA pulls in a bit, saves back a bit. While that is going
on userB is doing the same thing. A bit of userA's write to disk
steps on the bit userB is writing to disk and there you go;
conflict or corruption.

Except that this won't ever happen, because Access honors the locks
in the LDB file. Corruption happens only when something goes wrong
-- normal operation of a shared data file stored on a server will
never ever corrupt the data.

 

[David W. Fenton]

Okay I missed that while stored on the server that they were still
separate. In that case you would only suffer some performance
drag of having the file on the server instead of local.

In other words, there is no performance gain at all, since in that
case both the FE and BE have to be retrieved from the server.

Remember -- nothing happens on the server at all. The server is
equivalent to a hard drive attached to your local PC in terms of
what it does.

 

[Rick Brandt]

Except that this won't ever happen, because Access honors the locks in
the LDB file. Corruption happens only when something goes wrong --
normal operation of a shared data file stored on a server will never
ever corrupt the data.

I was talking about shared front end conflicts and corruption. That too,
should never happen, but experience suggests otherwise.

 

[David W. Fenton]

I was talking about shared front end conflicts and corruption.
That too, should never happen, but experience suggests otherwise.

Well, to be fair, it only happens for front end objects, and not for
data tables, and is likely a result of the monolithic save model
introduced in Access 2000, where the entire Access project is stored
as a BLOB in a single record of one of the system tables. Contention
for updates of that BLOB seems to me to be the main reason
corruption happens.