Re: What database shall I use???

Given that we have reliable reports here on a routine basis of multiuser Access applications with 30 - 70 users, even when not all the factors are perfect. If all the factors are near-perfect, then clearly (again from reliable reports here) you can exceed 100 users on an Access front-end, Jet database application.

Same is true of size... many here work with all-Access databases with hundreds of thousands of records, with satisfactory performance. Some, interestingly, have actually used the trick of linking to tables in multiple Access databases to exceed the 1GB(through Access 97) and 2GB (Access 2000 and later) size limits.

You just gotta know what you're doing and not give up when you've done enough wrong that your performance goes to Hell with much smaller databases and much smaller user audiences.

We are all familiar with corruption issues... when was the last time your "computer bombed" and caused corruption? I can count on the fingers of one hand, and have some left over, the number of times any client's corruption was due to a computer going down; dropped network connections due to intermittent NIC errors, yep; once in a while, a power outage without backup power, yep; even users who powered down (but once found out, they didn't do it again, because 'graceful termination' became a 'condition of continued employment').

Your claims of limitations are ridiculously low for any Access database and environment for which virtually all the factors aren't drastically wrong: requirements, design, and implementation of the database, and the hardware, software, and network environments. On the other hand, they are typical of server database types who tried Access once, but couldn't be bothered to learn it well enough to do it well. I certainly don't know enough about you to put you in that class, but your comments certainly tend to be in agreement with theirs.

"corey lawson" <corey.lawson_at_worldnet.att.com> wrote in message news: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. MSDE (MS Sql Server 7 "personal"
> edition) has similar limitations, but at least if you've connected to
> it, you can throw a faster server at it for awhile. Since Access
> linked to remote Access files is pure file-server access, it can
> really get killed if the table size gets >10,000 records.
>
> Throw in potentials for MDB corruption, say, if a user's PC bombs in
> the middle of an edit, the use of VBA functions in fields that have
> criteria or as criteria in queries (which cause Jet to slurp much more
> data than necessary to process it on your local computer...)...
>
> At least backups of MDB files are simple!
>
> On Tue, 05 Mar 2002 18:17:04 GMT, "Glen A Stromquist"
> <gstromquist_at_nospamyahoo.com> wrote:
>
> >My 2 bits worth -
> >
> >If you are not looking at a huge number of tables/users and/or
complexity,
> >Access might do the job for you, if you are looking at large numbers of
> >users accessing at the same time then definatly not, although Access
still
> >can be used for a "front-end" for a SQL Server or Oracle database, which
> >IMHO is far to "buggy" for this purpose and there are better
alternatives.
> >
> >I have built a few simple applications in Access, quite small database
wise
> >and there was enough bugs to keep me busy for quite awhile when they were
> >initially deployed. It would give me nightmares to think of a large
mission
> >critical application being deployed in Access alone.
> >
> >If you want rock solid security and data integrity go with a true RDBMS,
> >such as SQL Server or Oracle, the latter being my preference ( I
> >administrate both of them)
> >
> >hth
> >
> >
> >
> >"Albert D. Kallal" <kallal_at_msn.com> wrote in message
> >news:Zz6h8.219319$A44.13555535_at_news2.calgary.shaw.ca...
> >> Microsoft spent a considerable amount of money and effort on
> >> the new versions of this product. The new features allow Access to work
> >> as a native front end to sql server. This is a NATIVE CONNECTION
> >> with no local tables.
> >>
> >> This means Access is now a very
> >> scalable product, and can be used in the Corporate environment. MS
clearly
> >> considers the server based database market a key technology in their
farm
> >> of products. Any product that encourages the use of their server
products
> >> is clearly a strategic and important product.
> >>
> >> It is interesting, but Access is now kind of two products. It is
possible
> >> that the new Access ADP project builder should have been called SQL
> >> "CLIENT BUILDER". In fact, they probably should have done this. In
other
> >> words they should have re-named the product to sell to the corporate
> >> market. In addition, they could have kept the Access name (hence, sell
the
> >> *exact* same product with two different names). Microsoft really missed
a
> >> big opportunity here.
> >>
> >> I believe that this name change was not done due to the very large user
> >> base that Access already had. It really was a catch 22. The real reason
> >> to change the name is that Access has a *very* bad "taste", or "image"
> >> in the corporate market. This image was one of Access not being a
> >> industrial strength database. It is common to hear many database people
> >> say that Access is a toy
> >>
> >> With the "ADP" feature of Access, it is now
> >> a true client product, and thus can be considered a true corporate
tool.
> >It
> >> also means that Access CAN NOW BE used in Mission Critical
applications.
> >>
> >> For large mission critical applications Access is not appropriate
> >> when used with *NO* server.
> >>
> >> You also have to understand that Access is not a database server, but
> >really
> >> is only a client to some type of database. That database can even be
> >Oracle.
> >>
> >> Thus, even when you choose Oracle as your server, you still have to
decide
> >> what tools, and what you are going to use for the client.
> >> --
> >> Albert D. Kallal
> >> Edmonton, Alberta Canada
> >> kallal_at_msn.com
> >>
> >>
> >>
> >
> >
>
Received on Sun Mar 10 2002 - 23:17:56 CST