Re: MS Access usefulness and size restrictions

"wayne" <no_at_email.please.com> wrote in message news:9fsdag$1oc_at_dispatch.concentric.net...
>
> > 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).

Actually, that *is* my point...you can scale the product, use a server with it. Why do we want to limit the context here?...This is EXACTLY my point! What other product in market has that kind of nice mix? We are making a suggestion here..are we not?...or is this just a mud sling?

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

As compared to what?.It is only a big task to those lack the skills. In addition, the current version of Access allows you to develop in manor that will scale correctly (that is what the MDSE is all about....it is a sql 7 compatible server.). Any ADP projects should be created with this in mind.

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

Ok, I understand now...however, I am not convinced on that one. Clipper stored data as a fixed length, where as Access uses a variable length record structure. With the addition of Rushmore (attainted and borrowed from FoxPro when ms purchased that company), Access (and FoxPro) were *considerably* faster than the other pc based products when querying data (the benchmarks of those days in fact caused a lot of developers to jump over to Fox from dbaseIII, and also from clipper......clipper code was the fastest...but not its ability to query data). This issue becomes one of a well tuned Clipper app, and a well tuned Access application. In both cases, these products can do amazing things without a server....*if* you know what you are doing.

To come here and boast about clipper being solid, and then ignore people who have had in excess 100 people using access without a server is really puffing. If you know what you are doing, then clipper is great....and so is Access. Skilled developers will do wonders from both camps. I think the actual performance in Access will be in general faster, but that is much due to how a newer application would be designed (and it is newer tool, and has the benefit of sql and jet..when talking about NO sever).

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

Well, yea or (duh!). You are currently arguing about JET...which I could *easily* argue that is not part of access. All these methods are simply library functions of some type. In fact, you can run Access without it. I mean, the vb folks use jet to access mdb files...not a big deal. However, why did I bring up? The POINT here is that we can use this stuff. The other point is that the results of a sql statement can be put into a recordset, or an array. (you could not do this in Fox when you used sql). Again, this also why I believe that JET would perform much faster than clipper in a large application. (this is because code execution speed is not the problem...it is bandwidth...and jet is way a ahead of clipper here...and our data files will be 1/2 the size).

> We are not talking about Oracle. We are talking about Access as a
 database,
> not a database front end. Look at the past posts.

Well, that depends....does it not? I am simply stating that Access is a front end...and you have great flexibility. Also, when you create a project for use with the MDSE, your design will be one for sql server. If you need something larger, then scale up to a larger server....but the fact is, that Access does ship with a server engine.
>
> > I mean, Access is just a front end to whatever ever
> > database you are using...is it not?
>
> Not in this thread.
>

Well, you cry over spilled milk....but access does ship with a server.

However, to be fair, I do understand that people in this thread are NOT recommending that you use the MDSE (that means, I do make a effort to fairly see your point of view....I hope you do the same for me?).. In other words, we really are talking about JET (if we are to both be honest...I accept this...). However, that is simply due to the argument shifting from what the original poster should use...as to one of what JET can do.

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

Yes, but you are completely ignoring the fact that we can move on to sql server , or even oracle. What possible other desktop database can you suggest that scales up, on to sql server? The issues becomes is Access scaleable, and good solution when you consider all things?

> 1. No triggers in Access.

Well, as I said, that is moot point with the MDSE. The MDSE is included with access. In fact, they don't license it on a per seat use...but throttle it after 5 users. We saw some claims of up to 25 users...but at any rate...if you out grow the MDSE, then just move the data up to a larger server when you need to. What could possibly be a better design and deployment strategy here? We are trying to give advice here...are we not?

Again, I understand your point that you are NOT talking about the MDSE...but why are you limiting your suggestion? The issues here is does access ship with the tools to use triggers ?...jet no....MDSE...YES!

> Access then "scale" it to the bigger database you will have a very crappy
> design and you'll likely have to redesign it.

Again, that nonsense if you use the MDSE. The real issue here is to create a ADP project for use with MDSE for a small design, you end up with something that works for larger design.

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

Again, access includes a sql 7 compatible server. The whole idea here is when you create a ADP project is that Access does enable you to design correctly so that forms etc. are going to use server correctly. The environment now encourages one to design for scalability......this was not always the case with Access.

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

Again, that assumes a crappy design. Why not Design the project for the MDSE? The whole idea of creating ADP projects is to allow one to use a server based product. Ms-access completely ate up the pc based market. There is virtually no one else left.

Now, access has set it sights on the next market....that is one move that the industry should not take lightly. Even the way the engine licensed is very unique (they don't license per seat...but just throttle it.....). The end result of this is going to be lowered costs. This lower costs is in fact of a range that Oracle (and others) are not at all competitive. The problem here is that Access is starting to scale up well......it spells trouble for the amount of revenue that vendors will get on a per seat basis. That is how I see it. All the old arguments against access are falling like dominos.

If you are objecting to the limits of jet, then I have no argument with you. However, with Access we have choice now. All the criticism you have really centres around as to the choice to use a real server product with Access....not the fact as to if we should use Access.

When one moves beyond this issue of JET, then we can give a reasonable suggestion to the original poster.

Also, to the rest of the people in the ms access world, I think now it is *very* clear as to what the MDSE is all about...and this debate proves that!

My apologies for this cross post. I will trim the non ms-access newsgroups in any further responses to this thread.

Albert D. Kallal
Edmonton, Alberta Canada
kallal_at_msn.com Received on Sat Jul 21 2001 - 15:37:12 CDT