Re: MS Access usefulness and size restrictions

"wayne" <no_at_email.please.com> wrote in message <news:9fsdag$1oc_at_dispatch.concentric.net>...

> > As mentioned, many people have experienced much larger seat use. Thus the
> > question then becomes what was being done, and more importantly..*how* it
>
> You ansswered your own question: It depends on how you are using it. I used
> it for processing lots of financial data and it broke with 4-5 users with
> 250,000 daily appends in batch and mid-size querying.

How were these 250 000 daily appends being done? How many inserts or updates per transaction?

> Another application broke with 8 users in heavy transactional use -- about
> 1000 updates an hour, 500 inserts an hour on mid-sized (1000 bytes) records.
>
> > Hum, I never seen a product with more scalability. When correctly used,
> > Access makes a great front end for Oracle, or for whatever.
>
> Two things: 1) We are talking in the context of a database back end (if you
> can call Access a "back-end"; in the strict sense of client/server Access is

Access is a "file server" database. Who has claimed otherwise?

> NOT a server). And 2) The nature of Access is to want to do everything for
> you, so writing SQL pass-through queries and making it all work flawlessly
> is not trivial in Access. (Just based on my experiences and those of my
> colleagues).

Pass-through queries? We're no longer talking about using Access as the "back-end" database.

> >In fact, I'll
> > bet access is used a as front end for Oracle, more than any *other* non
> > Oracle product in the market.
>
> Well that draws a chuckle! Maybe VB, but Access?

If nothing else, Access is a damned powerful reporting tool.

> > it up to Sql server, or even Oracle. Do you actually think that Clipper is
 a
> > better solution here?...wow? I am missing something here
>
> It's called "example" and I was not suggesting Clipper. I was saying how I
> can handle a bigger workload with a desktop database much older than Access.
> Not trying to convert anyone, and the only reason those apps are still
> around is because Clipper works and is rock-solid, not because of any other
> reason.

Or simply because you knew Clipper better?

> >....clipper is scalable?
>
> I never said scalable (actually it is, you need to get the right libraries
> and it will really scale).
>
> >Is this your advice as a informed developer? Clipper is so simple
> > when compared to a modern language like vb.
>
> Oh, so now the more complexity, the better...

You're the one arguing for Oracle Everywhere. What are the license fees up to now, a new Lear for Larry every year?

> >In addition, the vb code allows
> > the use of sql to create record sets *in* code (ie: the data, and code
 work
> > seamlessly with sql) .
>
> Yipee! You have a replacement for an array! What a *vital* capability!

What, you move your multimegarecord tables into and out of arrays?

> BTW: That is a capability of ADO, not VB. Keep your products and tools
> straight!
>
> > Surely, you are not arguing that Clipper is a more robust and scale
 solution
> > then Access/Oracle .
>
> We are not talking about Oracle. We are talking about Access as a database,
> not a database front end. Look at the past posts.
>
> > I mean, Access is just a front end to whatever ever
> > database you are using...is it not?
>
> Not in this thread.

Then where are the pass-through queries coming from?

> > Build it in Access, and scale it to whatever your need.....what could be
> > more easy?
>
> That is a very bad mistake. Real databases have features Access does not:
>
> 1. No triggers in Access. Triggers are an integral and fundamental part of
> database design for larger databases. If you design/code a project in
> Access then "scale" it to the bigger database you will have a very crappy
> design and you'll likely have to redesign it.

Triggers were introduced as a work-around for the awful lack of real declarative referential integrity features in earlier RDBMS'. So now they're "fundamental"?

> 2. You cannot write back-end code in Access and then use it in the other
> database. You can simulate server-side code somewhat in Access, but when
> you port it over you have to rewrite it.

You'll also have to port code between Oracle and any other product. If Database product X doesn't want to interoperate with anybody else, is it really the fault of everybody else?

> Creating something in Access and then copying it to a bigger database is
> grounds for getting fired in my shop. That kind of crappy design
> methodology begs for extensive database design study, not for any kind of
> production work.

So a properly normalized schema is product-specific now? Breathtaking!

--
Joe Foster <mailto:jfoster@ricochet.net>  Space Cooties! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!