Any of these file based databases where there really isn't a server, but is
client based - which an Access database is - the corruption factor - which
when it hits does not tell you at the moment it occurs - is very dependent
upon the stability of ALL the pieces of the network. For example, I have
seen it have terrible problems in places where the infrastructure is not as
stable as yours presumably is. In non-IT places there can often be problems
with stable power which can wreck havoc on an Access and other file based
systems database.(They are just not designed for such abuse.) Granted
people should have stable networks, but the reality is that there is a lot
of variance in quality of infrastructure. Commercial RDBMS's (eg Oracle,
DB2 , et al) are designed to weather such abuses. They do cost more and
require more server hardware. But hey the right tool for the right need.
Jim
"David W. Fenton" <dXXXfenton_at_bway.net> wrote in message
news:91CEE9458dfentonbwaynet_at_news-server.nyc.rr.com...
> corey.lawson_at_worldnet.att.com (corey lawson) wrote in
> <3c8c2550.31870118_at_netnews.att.net>:
>
> >If you're only doing read-only access to Access [sic], then Access
> >isn't too bad, even for large MDB files. It starts bogging down
> >hard when your MDB size gets over ~20MB or so and >5 simultaneous
> >read-write users, generally.
>
> You're simply WRONG.
>
> Wrong.
>
> You obviously don't know how to design a properly functioning multi
> -user Access database.
>
> I have a client with a 375MB Access database (3 tables have over
> 300K records in them) with 5-10 simultaneous read/write users.
> Performance is just fine, there is no corruption and there are no
> concurrency problems.
>
> --
> David W. Fenton http://www.bway.net/~dfenton
> dfenton at bway dot net http://www.bway.net/~dfassoc
Received on Mon Mar 11 2002 - 22:44:27 CST
