Architecture BE FE vs Network

[Tony Toews [MVP]]

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.

That's because we're not quite sure.

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

Agreed. Not desired but your description is correct.

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.

Which one client did.

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

You could also write your own code to do something similar. There are
some links at the Auto FE Updater site to alternatives.

I will also add that some of the worlds largest companies are running
the Auto FE Updater. I've seen some very interesting corp names in
the emails I've received over the years.

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/

 

[James A. Fortune]

That's because we're not quite sure.

I agree with Tony. I'm not sure either. Either way, with that setup,
Access has to know what is happening on other machines via its polling
synchronization, whether by changes in local memory or by simply file
sharing the information. We're getting into the internals of Access and
the method Microsoft has chosen is not completely obvious, but as one
poster alluded to, multiple copies of Access on a user's hard drive
opening the same mdb file on the same hard drive should behave the same
except for the file sharing. For example, when I do that and modify one
of the queries, the changes show up when I open the query in the second
database instance. If I have the same query open in design view in both
instances and change the ORDER BY fields differently in both and then
try to save both, I get a message:

'qryMyQuery' has been changed since the last time you opened it, either
by another user or because another instance of it was opened on your own
machine.

Do you want to replace the changes...

Therefore my guess is that Access is using something like good old JET
replication to synchronize changes to the front end. So does Access
keep essentially an entire replica of the front end in memory? From a
user's standpoint, it doesn't matter how much of the mdb file is
actually brought into the Access executable, but from a conceptual
standpoint, something very important is happening. Any replication
system, whether it uses JET, SQL Server, Groove, multicore processor
threads, etc. attempts to do one thing. You want access to any of the
data on a network to be as fast as if it's stored locally on your hard
drive or even in RAM, or at least to seem that way. The whole purpose
of an entire computer science discipline known as Data Structures is to
move data from places where the access time is slow to places where the
access time is fast. No matter what smoke and mirrors method is used to
disguise the concurrency of the data, some situations reveal the man
behind the curtain.

In order to figure this out, I think I just need to know the right
questions to ask myself .

James A. Fortune
(e-mail address removed)