Can a data table handle 100 - 600 users with out an impact on his
Steve Stover
performance?
William Ryan
access strategy has a profound effect on it. Whether or not you are
implementing transactions, locks, leaving connections open etc also has a
profound effect. Query strategy is another one. the power of the servers
is probably the most significant (but then again, it's not necessarily the
most). Dotnetjunkies uses ASP.NET, and they have a huge volume just as an
example.
As a DBA, I can tell you this, just about anything is doable, it's a matter
of tradeoffs. can you do 600 users with MS Access and ADO.NET? No way.
But that's not ADO.NET's fault. ADO.NET is meant to work in a distributed
environment, that's what it's built for. So 20,000 users could be using an
ADO.NET app for instance, and depending on timing, only a few hundred may
even be connected.
If you are going to do that type of volume though, you really need to learn
ADO.NEt and its interaction with the DB. David Sceppa's ADO.NET Core
Reference is a must have, as is Bill Vaugh's ADO ADO.NET book. You'll
probably also want to get a book on the DB you are using for a backend (then
again, you could be using XML or Excel or whatever eslse) and learn about
the DB limitations.
The more details you can provide, the better suggestions NG members can help
you with.
Cheers.
Bill
"Steve Stover" <ssto...@cox.net> wrote in message
news:uzmp7Jmq...@TK2MSFTNGP10.phx.gbl...
onedaywhen
> can you do 600 users with MS Access and ADO.NET? No way.
> But that's not ADO.NET's fault. ADO.NET is meant to work in a distributed
> environment, that's what it's built for. So 20,000 users could be using an
> ADO.NET app for instance, and depending on timing, only a few hundred may
> even be connected.
I hate to appear as an apologist for MS Access but, reversing your
analogy and scaling as appropriate, surely 600 users could be using MS
Access via an ADO.NET app and, depending on timing, only a dozen may
ever be connected. So why do you say, 'No way'?
"William Ryan" <dotne...@nospam.comcast.net> wrote in message news:<OGioeCo...@TK2MSFTNGP11.phx.gbl>...
William Ryan
them were accessing the Database at any given time, then Access may do the
job. From his post, I didn't get the feeling that that's the scenario he
was asking about --- but I could be wrong. However, assume that it was for
a second. Let's say that out of the 600, 20 came back late from Lunch due
to traffic problems and now the number is 30 concurrent users. More than
likely there's going to be a problem. I've heard all the Access developers
claim that they programmed their app sooo well that they have 20 concurrent
users and never have a problem. I've never seen this with my own eyes, but
let's say that its true. I've worked in over 6 companies and two contracts
where I've seen Access apps explode on a regular basis with half that load.
That's totally ignoring the terrible performance being that Access isn't
designed to be a client/server db. As such, I think that unless you can be
100% certain that your user base of 600 users will never have more than 10
users, you are asking for trouble. Can it be done? Perhaps. Is it worth
the risk? Doubtful. Could I recommend in good faith that someone use
Access for an app that has 600 users when there is MSDE which is much
better suited to handle this type of load and costs less than Access? No
way. But I don't mean that it's physically impossible for 12 of 600 to use
access simultaneously...I'm just saying that as a production solution,
there's no way that someone would want to do that and deal with all of the
constraints you'd need to put on you app to ensure access didn't break.
I wasn't belittling access, I just think using it for large production loads
is like using a Screwdriver to pound nails. Screwdrivers are great tools,
but just aren't made to pound nails. You can use them as such, but is it
really worth it?
"onedaywhen" <oneda...@fmail.co.uk> wrote in message
news:b8c9d0b7.03111...@posting.google.com...
William (Bill) Vaughn
is gated by the fact that each users gets their own JET engine that has to
perform shared physical IO on a common file. This design was implemented in
Dbase back in the 70s on 8-bit computers and didn't work then. It still
doesn't work for more than a few users--unless these "users" are (mostly)
dormant. Sure, someone will pop up and say they connected a couple of
hundred users to a JET database but outside of a carefully constructed lab
experiment, I've never seen it in a "real" production environment.
MSDE is SQL Server. It's capable of scaling to as many users as most small
businesses need, and without changing the code can scale to thousands of
simultaneous (active) users when you convert to Standard or Enterprise
edition. JET can't say that. That's one reason why Microsoft is moving away
from JET--even for Access.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
"William Ryan" <dotne...@comcast.nospam.net> wrote in message
news:upsGAxuq...@TK2MSFTNGP11.phx.gbl...
onedaywhen
MS Access apologist; in fact I'm more likely to be accused of
belittling MS Access than defending Jet! I was merely querying a point
that I hadn't fully understood and the response was excellent. Many
thanks.
"William \(Bill\) Vaughn" <billvaRe...@nwlink.com> wrote in message news:<OEw38uwq...@TK2MSFTNGP11.phx.gbl>...