"ac*******@railvan.com" <ac*******@railvan.com> wrote in
news:11**********************@f14g2000cwb.googlegr oups.com:
One of the current backlashes we're getting from our IT group is
that MS is specifically saying that Access draws too much
resources from the memory pool.
Just to re-iterate what others have said:
The difference of memory profile between these two scenarios is
going to be completely negligible:
1. TS users running Access to share a single front-end MDB
2. TS users running Access, each opening their own copy of the
front-end MDB
Most of the RAM will be in supporting the virtual machine that
encapsulates the user's TS session. Both scenarios will have the
same memory usage once Access is running and before an MDB is open.
Since each user loads the MDB from the same image into their own
RAM, it doesn't matter from a RAM usage point of view whether all
the users are opening the same MDB image stored on disk or opening a
unique image from their user profile.
The only actual differences in this regard are:
1. disk caching -- opening a single MDB could possibly be more
efficient because of disk caching. However, given that a shared MDB
is going to have locking issues (since data does get saved back to
it, unless you work very carefully to eliminate as many of those
saves as you can -- you can't eliminate 100% of them), the image may
need to be refreshed from the disk image, anyway, and so the disk
caching may not get you as much benefit as you think.
2. disk space -- if you've to 30 users, you need 30 times the disk
space for storing the front-end MDBs. But a typical front end is
going to 5MBs or less, so that's 150-200MBs at most, which on
today's servers, is a completely trivial amount of disk space.
And these things do *not* take into account the additional overhead
of managing the record locking on a shared front end, which could
very well be significant. Add to that the extreme risk of corruption
with a shared front end (it was not a great problem in A97 and
berore, but is a major problem in A2K and later), and you can see
that by trying to reduce a trivial amount of RAM usage, you are
actually creating a huge number of administrative headaches.
In short, your IT group is being penny-wise and pound-foolish.
--
David W. Fenton
http://www.bway.net/~dfenton
dfenton at bway dot net
http://www.bway.net/~dfassoc