Can a multi user Access db be used via Terminal Services?

[Paul H]

Say I have a Windows 2000 server running Terminal Services with a single
file Access DB (not front end/back end) on it, could multiple users access
the data base simultaneously?
Paul

[Rick Brandt]

Paul H wrote:

Say I have a Windows 2000 server running Terminal Services with a
single file Access DB (not front end/back end) on it, could multiple
users access the data base simultaneously?
Paul

They could do so exactly as they could if Terminal Services was not involved.
Meaning that it can be done, but it would not be recommended unless they app
were split with each user getting a separate copy of the front end.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[acuttitta]

What of databases were multiple users were in, but not utilizing the
same objects?

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.

[Chuck Grimsby]

There are several answers to this.... Mostly having to do with how the
Access program is programmed, and what technologies are used within
the Access database.

Generally speaking, the utility that most IT people use to monitor
memory usage doesn't _accurately_ reflect that Access uses a _very_
low priority memory thread that Access will gladly give up to just
about any process that wants more memory. In other words, the
reporting tool is reporting incomplete information. ("100% usage!
Man, that Access is a hog!" What they don't see is that the priority
of that usage is so low that moving the mouse causes Access to release
that memory.)

The above said however, there are also programming methods that can
indeed really "hog" a system. Opening and closing a form a bunch of
times for example, or failure to set objects to nothing and assuming
that Access will clean up after you, can indeed have a significant
drain on system resources.

There are a number of articles in the Knowledge base that address this
issue, and it can become quite complex.

On 28 Sep 2005 13:43:26 -0700, "ac*******@rail van.com"
<ac*******@rail van.com> wrote:

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.

--
Drive C: Error. (A)bort (R)etry (S)mack The Darned Thing

[Rick Brandt]

ac*******@railv an.com wrote:

What of databases were multiple users were in, but not utilizing the
same objects?

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.

That reduces the likelyhood of corruption, but it's still not a good idea.

Right now you have mutliple users using the same file but each has his own
Access session in memory. Giving them each their own copy of the front end
file is not going to siginifcantly change how much resources they use.

If you are using Access 97 on Windows Server 2003 then that could be part of
your resource problem. Access 97 has always grabbed as much CPU as it could
get, but in a low priority (most of the time) so it wasn't a problem. We
found when we upgraded to server 2003 that it suddently WAS a problem and
had to stop using Access 97 on our Terminal Servers.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Dean]

A total different way to do is putting your db on the web. I do this
all the time using ASP. The downside is your forms and reports will
not work as they are (on the web). They would need rewritten in ASP.
Also a desktop db can access a web db via odbc. That means your
reports could still be used then.

Someone else might have a different solution. The cool thing here is
the only service used is what Internet Explorer uses. It's great for
Data Entry folks. Also, it inexpensive to maintain and you can host it
on a web server for about $5 per month that should help the IT folks
stop bitching. Folks can login from anywhere. Plus you can have about
200 simutanous users using Access 2003.

[Dean]

A total different way to do is putting your db on the web. I do this
all the time using ASP. The downside is your forms and reports will
not work as they are (on the web). They would need rewritten in ASP.
Also a desktop db can access a web db via odbc. That means your
reports could still be used then.

Someone else might have a different solution. The cool thing here is
the only service used is what Internet Explorer uses. It's great for
Data Entry folks. Also, it inexpensive to maintain and you can host it
on a web server for about $5 per month that should help the IT folks
stop bitching. Folks can login from anywhere. Plus you can have about
200 simutanous users using Access 2003.

[David W. Fenton]

"Dean" <de**@coveyacco unting.com> wrote in
news:11******** *************@g 47g2000cwa.goog legroups.com:

A total different way to do is putting your db on the web. I do
this all the time using ASP. The downside is your forms and
reports will not work as they are (on the web). They would need
rewritten in ASP. Also a desktop db can access a web db via odbc.
That means your reports could still be used then.

Someone else might have a different solution. The cool thing here
is the only service used is what Internet Explorer uses. . . .

No one with the slightest amount of sense uses Internet Explorer as
their browser.

And no one with half the brains god promised a ham sandwich would
hard code IE-dependent features into a browser-based application.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"ac*******@rail van.com" <ac*******@rail van.com> wrote in
news:11******** **************@ f14g2000cwb.goo glegroups.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

[Dean]

No, you misunderstood. It is not hard coded to Internet Explorer. Any
web browser that can understand ASP would work just fine.