Re: MS Access usefulness and size restrictions

> 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.

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 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).

>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?

> 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.

>....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...

>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!

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.

> 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.
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.

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. Received on Sat Jun 09 2001 - 00:48:00 CDT