"Albert D. Kallal" <PleaseNOOOsPAMMkallal@msn.com> wrote in message
news:YMHQc.26773$M95.21859@pd7tw1no...[color=blue]
> "XMVP" <access_morons@hotmail.com> wrote in message
> news:s-WdnQ8QPPM_l47cRVn-og@vnet-inc.com...
>[color=green]
> > I think you're splitting hairs. What you're arguing sounds like[/color][/color]
something[color=blue][color=green]
> > out of "Computer Metaphysics 101," where a bunch of students sit around
> > asking questions like WHAT IS A DATABASE? Or maybe, WHEN IS A DATABASE[/color]
> NOT[color=green]
> > A DATABASE?
> >
> > "Database" is just a general term to describe an assortment of files
> > (programs, libraries, etc.) that work together to achieve a desired[/color]
> result.[color=green]
> > It makes no difference if the files are all from the same vendor and[/color][/color]
come[color=blue]
> on[color=green]
> > one CD or if they come from many vendors on many CDs.
> >
> > Look at it this way. If you bought a car you'd expect it to have an[/color]
> engine[color=green]
> > right? Why? Because it won't function without an engine. But it would
> > still be a car. What else can you call it?
> >
> > Microsoft throws in one or two engines with every copy of Access so they[/color]
> can[color=green]
> > call Access a "database."[/color]
>
> Actually, this issue is more then just splitting hairs, or one of[/color]
semantics[color=blue]
> here.
>
> I mean, it is rather silly to compare ms-access to Oracle?
>
> Sure, lets compare JET to Oracle, or the MSDE to Oracle , or sql server to
> oracle.
>
> If you speak of ms-access as product, then it has data engines, and also[/color]
has[color=blue]
> a IDE. In fact, we are talking about a data client development tool.
>
> We certainly could and should compare ms-access to the Oracle client tools
> (The Oracle forms developer suite).
>
> So, yes, we can call ms-access a database by many definitions as you show[/color]
(I[color=blue]
> am not disagreeing on that). In fact, based on the many links for data[/color]
defs[color=blue]
> you have, then we can call VB, or c++ a database by those defs (if you
> include the JET dao library with those products, and, this is often
> done...especially with VB)
>
> However, for the sake learning something, ms-access is more of client
> development tool then it is a database. So, sure, lets compare the Oracle
> Forms Developer Suite to ms-access.
>
> However, I am at a loss as to how (or why) we would compare VB to Oracle,[/color]
or[color=blue]
> compare c++ to Oracle, or ms-access to Oracle????
>
> Unless some clarification of the database engine is made, the term
> "ms-access" is much too loose to define what is to be compared to Oracle.
>
> So, yea...we can say they both are cars...but lets not compare the seats[/color]
in[color=blue]
> one car to the engine in the other car...it don't make sense to do that.
>
> Lets not compare the tires on one car to the engine on the other car....
>
> To learn and have a discussion on, this matter...we will need to define[/color]
what[color=blue]
> is to be compared. So, sure, lets compare ms-access forms against the[/color]
Forms[color=blue]
> tools in Oracle....I have no probelm with that...
>
> --
> Albert D. Kallal (Access MVP)
> Edmonton, Alberta Canada
>
pleaseNOOSpamKallal@msn.com
>
http://www.attcanada.net/~kallal.msn
>
>[/color]
All you're saying is that some software products have more of the "parts"
needed to build a database and other software products don't have enough.
If we're talking about a "total solution" database product, meaning a bundle
of files that when used in various combinations produces a finished product
everybody recognizes as a "database," or maybe more accurately as a
"database application," then Access beats all the other products you
mentioned. It has form objects to input data, table objects to store data,
report objects to output data, and various other objects to manipulate,
relate, and maintain data. (Okay so it has no security!)
The original poster IMPLIED that Access and Oracle were interchangeable
products--that either could be used to build a total database solution,
which of course is not true, as you pointed out. I don't take exception to
that. The implied comparison is obviously faulty.
But I do take exception to the idea that Access should be "deconstructed"
and its parts compared to the parts of other database products, which is
what you seem to be saying. Under your analysis, Access is essentially a
product for developing front ends, i.e., the user objects. That's wrong.
It's a product for developing total database solutions, no matter if those
solutions come with a crappy little four-cylinder engine. Oracle or SQL
Server, to the contrary, are not total database solutions, although they
have monster engines, to extend the metaphor.
So if we want to compare parts, then Access will win some comparisons and
Oracle or SQL Server will win other comparisons. But if we're talking about
a total database solution as the definition of a "database," then Oracle or
SQL Server are not even in the running.
I understand what you're getting at, that Access is seen by most
professional database developers (and by Microsoft to some extent) as merely
an IDE for making front ends for use with some other back end, what you call
a "client development tool." But that assertion, while fairly accurate, is
also somewhat misleading because client development tools generally produce
standalone programs (executables).
Off topic, I will also say this. Access has become the bastard child of
Microsoft. The company would disown it if it could because there's almost
no market for a "desktop database" these days, which is what Access was
originally designed to be. Now, nearly everybody has at least a little LAN
running and a server someplace that could easily accommodate a 5- or 10-
client license SQL Server setup. Access needs to be folded into SQL Server
and disappear from the face of the earth.
