Re: MS Access usefulness and size restrictions

Must have been a bunch of really poorly-designed and poorly-implemented databases or really bad decisions in the first place as to what tools to use.

As I said, I've done a bit of Access <-> various server (but none in need of the strength of Oracle) for Fortune 500 and some Fortune 50 companies, and, yep, some all-Access databases for the same client-set. You imply that they have abandoned all but Oracle, but that is not, of course, the case. The user base, particularly for large audiences, of MS SQL Server is, last I heard, outpacing Oracle. But, I've hedged my bets -- I have stock in both. And, IMNSHO, if I had a project requiring the biggest, heaviest-duty, most industrial-strength, tool, that'd still be Oracle. OTOH, Microsoft _is_ going after that market, and everybody in it had better not dilly-dally.

And, good for you if you're making twice as much with Oracle Forms. I making three times as much with Access as I did on my first contract work after I retired from IBM back in 1991, doing some heavy-duty mainframe stuff. Does that mean anything? Nah. That was a long time ago, and I was subcontracting then.

Appropriate technology, young friend, appropriate technology.

Don't propose Oracle for a 5-user database. Don't propose all-Access for a 2,000 user database. Or, go ahead and propose either and let yourself get laughed out of the client's shop -- no skin off my back.

"Daniel A. Morgan" <Daniel.Morgan_at_attws.com> wrote in message news:3B2664D4.99AD3EFC_at_attws.com...
> Larry Linson wrote:
>
> > Comments interspersed.
> >
> > "Daniel A. Morgan" wrote
> >
> > > 1. You know for a fact you will never need to scale your application
 for
> > > more data and/or more users.
> >
> > More than _how much_ data and _how many_ users, Daniel? Reported in the
> > Access newsgroup with some regularity are multi-gigabyte databases and
 50-70
> > users. No knowledgeable Access person is going to recommend an
 all-Access
> > solution for terabyte databases or hundreds of users. However, they
 might
> > well recommend Access as the client for a server database in those
 ranges.
> >
> > You'd be laughed out of the building by any knowledgeable client if you
> > suggested an Oracle installation for ten, or twenty, or thirty users,
 unless
> > there were compelling reasons other than the user audience.
> >
> > > 2. Security is irrelevant.
> >
> > I caution everyone that someone can crack any security scheme if you let
> > them get their hands on the application/database. That will hold true
 for
> > server databases, as well, if you let them get control of the server.
> > However, I'd wager a cuppa coffee or other beverage that there are
 people
> > participating in comp.databases.ms-access who could secure and send you
 a
> > database that you couldn't crack in any reasonable time for any
 reasonable
> > amount of money with the available cracking tools. I'd also wager
 another
> > cuppa, though, that that database, if enough time and effort were
 applied by
> > knowledgeable parties, could be cracked. It's just another one of those
 "how
> > much is it worth" judgement calls.
> >
> > > 3. Your environment is pure Microsoft.
> >
> > Joe's pointed out one alternative. But, without any "tools", I've run
> > all-Access solutions in environments that were not, repeat _not_, pure
> > Microsoft. Of course, Access and Jet must run in Windows or a Windows
> > simulator, but I've had mutliple users accessing a separate Access
 tables
> > database that resided on an HP-UX server.
> >
> > > 4. You don't have a background in stable computing where being
 BSOD'd
 drives
> > > your blood pressure up.
> >
> > Perhaps I don't... I've only been in the business since 1957, and among
> > other things, worked on the system that protected you from Soviet manned
> > bombers, the system that got our folk to the moon, and the one that is
> > likely still involved in over half your credit card transactions. None
 of
> > those were done in Access, of course, but not every application demands
 24/7
> > ultra-reliability, and certainly not every tool other than Access
 provides
> > it.
> >
> > > To me Access is one step above 3x5 cards.
> >
> > Well, I'll have to say the same to you as to wayne, "I'm sorry for you,
 my
> > friend." unless of course, you have the smartest deck of 3x5 cards that
> > anyone every imagined.
> >
> > > The cost of a database application is never
> > > in the software purchased from the vendor.
> >
> > Well, that would depend on the application. Some applications are of
> > sufficient scope and magnitude that what you say is true. The vast
 majority
> > are of a scale where the cost of the software is a consideration.
> >
> > > It is in the design, implementation, testing, and long-term
> > > maintenance. Within three years your Access app will be worthless.
> >
> > That is an interesting statement, considering there are people using
 daily
> > Access 2.0 applications I developed in 1994 and 1995. I'd have been
 pleased
> > if they'd run out of steam and had to call me back to upsize, but that
 just
> > wasn't the case.
> >
> > > The Oracle app will still be as stable as a rock and capable
> > > of being migrated to the latest version of the RDBMS in a
> > > matter of minutes.
> >
> > Daniel, only a fool would confuse the environments in which to use a
> > client-server solution with Oracle as the back end or an all-Access
> > solution. If you think that is even a possibility, you need to revisit
> > Relational Database 101. If you want to argue "Oracle versus
 <something>",
> > then you need to choose a server database as the something.
> >
> > Oracle is certainly an appropriate solution for a large range of
 problems,
> > often in combinarion with clients prepared in Access. On the other hand,
> > Access (and the supplied Jet engine) is certainly an appropriate
 solution
> > for a large range of problems. Anyone who doesn't understand that is in
 the
> > wrong business if they tout themselves as a 'database specialist'.
> >
> > On the other hand, perhaps you don't acknowledge that anything less than
 the
> > huge, heavy-duty, industrial-strength, 24/7, ultra-reliable applications
> > are, in fact, "database applications".
> >
> > Appropriate technology, young friend, appropriate technology. My last
 time
> > at Boeing, FYI, was in 1959, before I moved on to more fertile fields.
>
> Assuming what you say is correct, perhaps you can explain why it is the
 Fortune
> 500 companies such as Boeing and AT&T spend hundreds of millions of
 dollars
> migrating software from Access and SQL Server on Windows to Oracle and
 DB/2 on
> UNIX and never the other way around. And amazingly enough ... always due
 to user
> complaints which stop after the migration.
>
> Must be a bunch of really dumb end-users huh?
>
> Daniel A. Morgan
>
Received on Sun Jul 22 2001 - 01:47:33 CDT