Access vs SQL

[Scott M.]

Re: Access vs SQL

By the way, did you even bother to READ this:

From:

http://www.microsoft.com/resources/d.../jetintro.mspx

"Since its introduction in 1992, the Microsoft Jet database engine has been
in a unique position. Because Microsoft Jet is not a stand-alone product -
you cannot buy it at your local software retailer - most developers who use
it have learned about its functionality in a second-hand fashion from the
documentation included in Microsoft Access, Microsoft Office, Microsoft
Visual Basic®, Microsoft Visual C++®, or Microsoft Visual J++®. "

"Cor Ligthert" <notmyfirstname @planet.nl> wrote in message
news:%23uSx4C5P FHA.1500@TK2MSF TNGP09.phx.gbl. ..[color=blue]
> Scott,
>[color=green]
>> Cor, the subject may be Access vs. SQL, but the topic quickly turned to
>> JET and Access. The fact that you want to ignore what we have actually
>> been talking about here (including your own comments), just tells me that
>> you have nothing else to offer.
>>[/color]
>
> We ????
>
> There was only one person beside later you, who in this thread told that
> access was not a db.
>
> This is from your first message in this thread.[color=green]
>>Access does not implement any db security (beyond a db password)[/color]
>
> And now Access is no more a db, why has it than a db password.
>
> Scott, whatever you write in newsgroups can be checked, so watch what you
> write.
>
> However in the last sentence from your last message you are right, I have
> nothing more to offer in this thread, everything is already written in
> this thread and that was already before you started beating that dead
> horse.
>
> Cor
>
>[/color]

[lgbjr]

Re: Access vs SQL

Hi All,

LOL! I've quite enjoyed reading all of the posts in this thread. To get back
to the original topic for a second, I just wanted to let everyone know what
I decided to do.

I downloaded and installed MSDE 2000 (as well as DBAMgr2K). I did an upsize
from Access, tweaked my app a bit, and viola, everything works.

while downloading and installing MSDE 2000, my only thoughts were that
Access was simple (I'm always on a quest to keep things simple for my
users). MSDE 2000 adds a bit of complexity, but I have to say, compared to
the performance gains, it's well worth it. Two of the tables have OLEObject
(picture) fields (6 in one table, 8 in another). while running my app with
the "Jet or Access or MS Access" DB (wink), there was a noticeable delay in
retrieving and displaying records from the DB that had pictures. With MSDE,
pictures, or no pictures, retrieving records is fast!

thanks for all of the advice, and the entertainment!!

Lee

"lgbjr" <lgbjr@online.n ospam> wrote in message
news:ORcBmJXPFH A.2680@TK2MSFTN GP09.phx.gbl...[color=blue]
> Hello All,
>
> Thank You for your responses! All of you have given me quite a bit to
> think about!
>
> Richard, I understand completely. A bit of background: Even though I am
> developing a software package, I would not, by any stretch of the
> imagination, consider myself a software developer. I'm an Engineering
> Consultant for the Mobile Communications Industry. For the past 10 years,
> I've been writing PERL apps (when necessary) to automate repetitive tasks
> and make my life easier. These apps were for my use only. Over the years,
> I have had several clients ask me to provide these small apps to them. So,
> I moved from writing plain code, to writing an app with a user-friendly
> interface. Now, my clients want more. And they're willing to pay for it
> (above and beyond what they pay for my engineering services). Fortunately,
> I knew enough to write a scope of work (basically for myself), just as I
> would do for a typical engineering project. So, I do understand 'creeping
> scope'.
>
> Regarding the ability to 'Plug and Play' a variety of DB engines, I have
> considered this as well. At the beginning of this project, I was using C1
> Express components (no data adapters, no datasets, just Express Tables and
> an Express connection (OLEDB)). While this was extremely easy to
> implement, I realized that there was no upgrade path (upgrade = rewrite).
> Now, still using C1 components, I know (think) I can upsize to MSDE or SQL
> Server with only minor code changes.
>
> Gerald, I agree. Rather than trying to decide which DB engine is better,
> it's safe to say that all are good, if used in the environment they were
> designed for. Right now, wihtout thinking about growth, I could deploy
> with Access (1-2 users performing updates, additional 3-4 users viewing
> data, approximately 1-1.5GB size). But, this, based on what I have read,
> and your comments, is near the upper limit of what Access was designed
> for.
>
> JL, though it may not seem so, I am in a similar situation regarding IT
> support. Even though all of the mobile operators have extensive IT
> departments, the engineering and IT departments are always fighting. So, I
> need my app to be self-maintainable.
>
> After posting this, I'm going to install SQL2KDesktop (MSDE) and try to
> get a feel for what it will take to do a migration (I already have SQL
> Server running on another machine). I like Richard's idea of allowing the
> client to decide which DB engine to use. Hopefully my coding and
> forward-thinking was robust enough to allow this with only some minor
> tweaks. However, if I get lost in a sea of errors, I think my backup will
> be to use MSDE.
>
> Again, thanks for your insights!!
>
> Regards,
> Lee
>
>
>
> "lgbjr" <lgbjr@online.n ospam> wrote in message
> news:exGmoIPPFH A.2144@TK2MSFTN GP09.phx.gbl...[color=green]
>> Hello All,
>>
>> I've been developing a VB.NET app that requires the use of a DB. Up to
>> now, I've been using Access. It's a bit slow, but everything works. I'm
>> at a point now where I need to decide if I should stay with Access or
>> move the DB to SQL. I'm trying to come up with a list of Pros/Cons for
>> such a move. My list is a bit lopsided, as I have very little experience
>> with SQL and quite a bit with Access.
>>
>> PROS for moving to SQL:
>> Increased Performance?
>> Increased Reliability?
>> Lifecycle of Access?
>> Future Access Version compatibility issues?
>>
>> CONS for moving to SQL:
>> My limited knowledge of SQL
>> Clients not required to have an SQL server
>>
>> I've added a few items to the PROS list, but with ?s, as I don't really
>> know.
>>
>> If there are a few Access advocates and SQL advocates out there that
>> could give me some viewpoints, I'd be more comfortable making a decision
>> based on the facts, rather than my limited knowledge.
>>
>> TIA
>> Lee
>>
>>
>>[/color]
>
>[/color]

[Scott M.]

Re: Access vs SQL

You are on the right path Lee. Good luck!


"lgbjr" <lgbjr@online.n ospam> wrote in message
news:uB6s%23HDQ FHA.604@TK2MSFT NGP10.phx.gbl.. .[color=blue]
> Hi All,
>
> LOL! I've quite enjoyed reading all of the posts in this thread. To get
> back to the original topic for a second, I just wanted to let everyone
> know what I decided to do.
>
> I downloaded and installed MSDE 2000 (as well as DBAMgr2K). I did an
> upsize from Access, tweaked my app a bit, and viola, everything works.
>
> while downloading and installing MSDE 2000, my only thoughts were that
> Access was simple (I'm always on a quest to keep things simple for my
> users). MSDE 2000 adds a bit of complexity, but I have to say, compared to
> the performance gains, it's well worth it. Two of the tables have
> OLEObject (picture) fields (6 in one table, 8 in another). while running
> my app with the "Jet or Access or MS Access" DB (wink), there was a
> noticeable delay in retrieving and displaying records from the DB that had
> pictures. With MSDE, pictures, or no pictures, retrieving records is fast!
>
> thanks for all of the advice, and the entertainment!!
>
> Lee
>
> "lgbjr" <lgbjr@online.n ospam> wrote in message
> news:ORcBmJXPFH A.2680@TK2MSFTN GP09.phx.gbl...[color=green]
>> Hello All,
>>
>> Thank You for your responses! All of you have given me quite a bit to
>> think about!
>>
>> Richard, I understand completely. A bit of background: Even though I am
>> developing a software package, I would not, by any stretch of the
>> imagination, consider myself a software developer. I'm an Engineering
>> Consultant for the Mobile Communications Industry. For the past 10 years,
>> I've been writing PERL apps (when necessary) to automate repetitive tasks
>> and make my life easier. These apps were for my use only. Over the years,
>> I have had several clients ask me to provide these small apps to them.
>> So, I moved from writing plain code, to writing an app with a
>> user-friendly interface. Now, my clients want more. And they're willing
>> to pay for it (above and beyond what they pay for my engineering
>> services). Fortunately, I knew enough to write a scope of work (basically
>> for myself), just as I would do for a typical engineering project. So, I
>> do understand 'creeping scope'.
>>
>> Regarding the ability to 'Plug and Play' a variety of DB engines, I have
>> considered this as well. At the beginning of this project, I was using C1
>> Express components (no data adapters, no datasets, just Express Tables
>> and an Express connection (OLEDB)). While this was extremely easy to
>> implement, I realized that there was no upgrade path (upgrade = rewrite).
>> Now, still using C1 components, I know (think) I can upsize to MSDE or
>> SQL Server with only minor code changes.
>>
>> Gerald, I agree. Rather than trying to decide which DB engine is better,
>> it's safe to say that all are good, if used in the environment they were
>> designed for. Right now, wihtout thinking about growth, I could deploy
>> with Access (1-2 users performing updates, additional 3-4 users viewing
>> data, approximately 1-1.5GB size). But, this, based on what I have read,
>> and your comments, is near the upper limit of what Access was designed
>> for.
>>
>> JL, though it may not seem so, I am in a similar situation regarding IT
>> support. Even though all of the mobile operators have extensive IT
>> departments, the engineering and IT departments are always fighting. So,
>> I need my app to be self-maintainable.
>>
>> After posting this, I'm going to install SQL2KDesktop (MSDE) and try to
>> get a feel for what it will take to do a migration (I already have SQL
>> Server running on another machine). I like Richard's idea of allowing the
>> client to decide which DB engine to use. Hopefully my coding and
>> forward-thinking was robust enough to allow this with only some minor
>> tweaks. However, if I get lost in a sea of errors, I think my backup will
>> be to use MSDE.
>>
>> Again, thanks for your insights!!
>>
>> Regards,
>> Lee
>>
>>
>>
>> "lgbjr" <lgbjr@online.n ospam> wrote in message
>> news:exGmoIPPFH A.2144@TK2MSFTN GP09.phx.gbl...[color=darkred]
>>> Hello All,
>>>
>>> I've been developing a VB.NET app that requires the use of a DB. Up to
>>> now, I've been using Access. It's a bit slow, but everything works. I'm
>>> at a point now where I need to decide if I should stay with Access or
>>> move the DB to SQL. I'm trying to come up with a list of Pros/Cons for
>>> such a move. My list is a bit lopsided, as I have very little experience
>>> with SQL and quite a bit with Access.
>>>
>>> PROS for moving to SQL:
>>> Increased Performance?
>>> Increased Reliability?
>>> Lifecycle of Access?
>>> Future Access Version compatibility issues?
>>>
>>> CONS for moving to SQL:
>>> My limited knowledge of SQL
>>> Clients not required to have an SQL server
>>>
>>> I've added a few items to the PROS list, but with ?s, as I don't really
>>> know.
>>>
>>> If there are a few Access advocates and SQL advocates out there that
>>> could give me some viewpoints, I'd be more comfortable making a decision
>>> based on the facts, rather than my limited knowledge.
>>>
>>> TIA
>>> Lee
>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

[Paul Clement]

Re: Access vs SQL

On Tue, 12 Apr 2005 13:12:30 -0400, "Scott M." <s-mar@nospam.nosp am> wrote:

¤ > Jet is the database access layer component for Microsoft Access. It does
¤ > not define any specific
¤ > type of database. It is not a product and many who use Access have
¤ > absolutely no awareness of Jet.
¤
¤ It's true that most who use Access don't know anything about JET. That only
¤ proves that Access wraps the JET database.
¤
¤ Tell me, what is the connection string in ADO or ADO.NET to connect to an
¤ .mdb file?

oConn.Open "Driver={Micros oft Access Driver (*.mdb)};" & _
"Dbq=c:\somepat h\mydb.mdb;" & _
"Uid=admin; " & _
"Pwd="

¤ Tell me, what is the only kind of data that DAO can connect to?
¤

DAO can connect to any number of database types including Microsoft Access and ODBC supported
databases such as SQL Server and Oracle and ISAM databases such as xBase, Excel, Paradox etc.


Paul
~~~~
Microsoft MVP (Visual Basic)

[Paul Clement]

Re: Access vs SQL

On Tue, 12 Apr 2005 13:19:48 -0400, "Scott M." <s-mar@nospam.nosp am> wrote:

¤ From:
¤
¤ http://www.microsoft.com/resources/d.../jetintro.mspx
¤
¤ "Since its introduction in 1992, the Microsoft Jet database engine has been
¤ in a unique position. Because Microsoft Jet is not a stand-alone product -
¤ you cannot buy it at your local software retailer - most developers who use
¤ it have learned about its functionality in a second-hand fashion from the
¤ documentation included in Microsoft Access, Microsoft Office, Microsoft
¤ Visual Basic®, Microsoft Visual C++®, or Microsoft Visual J++®. "
¤

Isn't that kind of what I said?

Do we now want to count the number of times the phrase "Jet database" and "Access database" are used
interchangeably ? Not much point is there. ;-)


Paul
~~~~
Microsoft MVP (Visual Basic)

[Scott M.]

Re: Access vs SQL

Uh, no it's not what you said at all. And, most importantly, if you read
this documentation you will see that the terms MS Access and JET are NOT
used interchangeably . In fact, throughout the article, Access is referred
to as the "Microsoft Access user interface".


"Paul Clement" <UseAdddressAtE ndofMessage@sws pectrum.com> wrote in message
news:retq51p1e9 mc3d3irv733kt7d gf58rjavt@4ax.c om...[color=blue]
> On Tue, 12 Apr 2005 13:19:48 -0400, "Scott M." <s-mar@nospam.nosp am>
> wrote:
>
> ¤ From:
> ¤
> ¤
> http://www.microsoft.com/resources/d.../jetintro.mspx
> ¤
> ¤ "Since its introduction in 1992, the Microsoft Jet database engine has
> been
> ¤ in a unique position. Because Microsoft Jet is not a stand-alone
> product -
> ¤ you cannot buy it at your local software retailer - most developers who
> use
> ¤ it have learned about its functionality in a second-hand fashion from
> the
> ¤ documentation included in Microsoft Access, Microsoft Office, Microsoft
> ¤ Visual Basic®, Microsoft Visual C++®, or Microsoft Visual J++®. "
> ¤
>
> Isn't that kind of what I said?
>
> Do we now want to count the number of times the phrase "Jet database" and
> "Access database" are used
> interchangeably ? Not much point is there. ;-)
>
>
> Paul
> ~~~~
> Microsoft MVP (Visual Basic)[/color]

[Scott M.]

Re: Access vs SQL

¤ Tell me, what is the connection string in ADO or ADO.NET to connect to an
¤ .mdb file?[color=blue]
>
> oConn.Open "Driver={Micros oft Access Driver (*.mdb)};" & _
> "Dbq=c:\somepat h\mydb.mdb;" & _
> "Uid=admin; " & _
> "Pwd="[/color]

What you've shown here is what driver to use. Drivers are yet another way
to "wrap" the actual functionality of connecting to the data source. You
are supplying a "satisfacto ry" connection string, while the actual DB
provider is "Microsoft.OLED B.JET.n.x" as seen in the more commonly used:

Con.Open "Provider=Micro soft.JET.OLEDB. 4.0.;Data Source=path"
[color=blue]
>
> ¤ Tell me, what is the only kind of data that DAO can connect to?
> ¤
>
> DAO can connect to any number of database types including Microsoft Access
> and ODBC supported
> databases such as SQL Server and Oracle and ISAM databases such as xBase,
> Excel, Paradox etc.[/color]

Actually it's true, I mis-spoke, DAO does support more than just Access,
however if you read the article I posted the link to, you will see this:

"You can use the ODBCDirect object hierarchy to work with ODBC data sources
without going through the Jet database engine."

So, when you use ODBC, you are not connecting to a JET database. But, when
you do use JET in DAO, you are now limited to JET databases (not SQL,
Oracle, etc.).

It's also interesting that in VB 6.0, if you make a Data Project and get
into the connection's properties and look at the OLEDB providers, you don't
see one for Access. What you do see is JET. And, if you select JET and
then move on to select the corresponding database, it is even more
interesting that the dialong box used to browse for these databases has only
one file type that it is filtering on - - .mdb.

The minutia of this thread has all but worn me out Paul. Read the article I
posted and you will see that your argument holds up on a very high level,
but not at the lower levels. There's nothing more I can say.

[Paul Clement]

Re: Access vs SQL

On Wed, 13 Apr 2005 23:44:44 -0400, "Scott M." <s-mar@nospam.nosp am> wrote:

¤ ¤ Tell me, what is the connection string in ADO or ADO.NET to connect to an
¤ ¤ .mdb file?
¤ >
¤ > oConn.Open "Driver={Micros oft Access Driver (*.mdb)};" & _
¤ > "Dbq=c:\somepat h\mydb.mdb;" & _
¤ > "Uid=admin; " & _
¤ > "Pwd="
¤
¤ What you've shown here is what driver to use. Drivers are yet another way
¤ to "wrap" the actual functionality of connecting to the data source. You
¤ are supplying a "satisfacto ry" connection string, while the actual DB
¤ provider is "Microsoft.OLED B.JET.n.x" as seen in the more commonly used:
¤
¤ Con.Open "Provider=Micro soft.JET.OLEDB. 4.0.;Data Source=path"
¤

Yes, but there isn't much point to this. The only reason that I posted that
connection string, which I don't recommend using, is to point out that both
Access and Jet can be used interchangeably . There is no right or wrong.

But the key point is that the Jet Database Engine is a subset of the Microsoft
Access application and that it does not have full control over all objects and
data stored in a Microsoft Access database. Only the Access application has this
capability whether it's via the Jet Database Engine or directly through the
Access application code.


Paul
~~~~
Microsoft MVP (Visual Basic)

[Paul Clement]

Re: Access vs SQL

On Wed, 13 Apr 2005 23:26:23 -0400, "Scott M." <s-mar@nospam.nosp am> wrote:

¤ Uh, no it's not what you said at all. And, most importantly, if you read
¤ this documentation you will see that the terms MS Access and JET are NOT
¤ used interchangeably . In fact, throughout the article, Access is referred
¤ to as the "Microsoft Access user interface".
¤

Yes, but in other articles and documentation it is not.

http://tinyurl.com/6acob


Paul
~~~~
Microsoft MVP (Visual Basic)

[Scott M.]

Re: Access vs SQL

That's because the "other" articles you refer to aren't discussing the
low-level architecture of what is actually storing the data in Access.

As I've said, in many situations the term "Access Database" is just fine to
convey the meaning of what you are trying to say. What we are discussing is
completely different than those high level discussions (such as the ones
returned by your search).

Just because I use 2 words interchangeable doesn't mean that they are the
same thing technically. For example, in the OO world, the terms "object"
and "class" are often interchanged and for many discussions that's fine.
But there is a world of difference between what an "object" actually is vs.
what a "class" actually is.

The article I've provided is specifically about the low-level understanding
of what JET actually is and it's relationship to Access.



"Paul Clement" <UseAdddressAtE ndofMessage@sws pectrum.com> wrote in message
news:tt4t5159pc 0f402duellmnoke vfoi6i482@4ax.c om...[color=blue]
> On Wed, 13 Apr 2005 23:26:23 -0400, "Scott M." <s-mar@nospam.nosp am>
> wrote:
>
> ¤ Uh, no it's not what you said at all. And, most importantly, if you read
> ¤ this documentation you will see that the terms MS Access and JET are NOT
> ¤ used interchangeably . In fact, throughout the article, Access is
> referred
> ¤ to as the "Microsoft Access user interface".
> ¤
>
> Yes, but in other articles and documentation it is not.
>
> http://tinyurl.com/6acob
>
>
> Paul
> ~~~~
> Microsoft MVP (Visual Basic)[/color]

[Scott M.]

Re: Access vs SQL

> Yes, but there isn't much point to this. The only reason that I posted[color=blue]
> that
> connection string, which I don't recommend using, is to point out that
> both
> Access and Jet can be used interchangeably . There is no right or wrong.[/color]

I agree that there is no right or wrong (although I too don't recommend the
the Access driver version). I also don't disagree that in *many* cases what
we are discussing is minutia and makes little difference. But, when you
start peeling back the layers of the Access product, you must begin to
separate the Access software product from the actual data store.
[color=blue]
> But the key point is that the Jet Database Engine is a subset of the
> Microsoft
> Access application and that it does not have full control over all objects
> and
> data stored in a Microsoft Access database. Only the Access application
> has this
> capability whether it's via the Jet Database Engine or directly through
> the
> Access application code.[/color]

Again, what you say is not in dispute, but needs further clarification. The
Access product does store additional information that JET does not (reports,
queries, forms, etc.) and an .mdb file is a file that holds the cumulative
data (the JET database as well as the proprietary Access information).
However, the main point I'm trying to drive home here is that the DATA
itself (not the forms, reports, queries, etc. that compliment the data) is
stored in a JET Database that MS Access simply wraps and extends. The
result is placed into an .mdb file. In this context, JET and Access are not
the same thing.

[Paul Clement]

Re: Access vs SQL

On Thu, 14 Apr 2005 12:33:58 -0400, "Scott M." <s-mar@nospam.nosp am> wrote:

¤ That's because the "other" articles you refer to aren't discussing the
¤ low-level architecture of what is actually storing the data in Access.
¤

What's the point? Access also can make database level modifications w/o Jet. The Jet Database Engine
does not completely define the architecture of an Access database. In any event, there would be no
Jet Database Engine w/o Access since that is the application from which it originated.

¤ As I've said, in many situations the term "Access Database" is just fine to
¤ convey the meaning of what you are trying to say. What we are discussing is
¤ completely different than those high level discussions (such as the ones
¤ returned by your search).

No actually that was never the discussion. The discussion involved a response to
aatcbbtccctc@ya hoo.com who claimed that an .mdb file is not an Access file.

¤
¤ Just because I use 2 words interchangeable doesn't mean that they are the
¤ same thing technically. For example, in the OO world, the terms "object"
¤ and "class" are often interchanged and for many discussions that's fine.
¤ But there is a world of difference between what an "object" actually is vs.
¤ what a "class" actually is.
¤
¤ The article I've provided is specifically about the low-level understanding
¤ of what JET actually is and it's relationship to Access.

Don't think I follow where you are going with this.


Paul
~~~~
Microsoft MVP (Visual Basic)

[Paul Clement]

Re: Access vs SQL

On Thu, 14 Apr 2005 13:10:57 -0400, "Scott M." <s-mar@nospam.nosp am> wrote:


¤ > But the key point is that the Jet Database Engine is a subset of the
¤ > Microsoft
¤ > Access application and that it does not have full control over all objects
¤ > and
¤ > data stored in a Microsoft Access database. Only the Access application
¤ > has this
¤ > capability whether it's via the Jet Database Engine or directly through
¤ > the
¤ > Access application code.
¤
¤ Again, what you say is not in dispute, but needs further clarification. The
¤ Access product does store additional information that JET does not (reports,
¤ queries, forms, etc.) and an .mdb file is a file that holds the cumulative
¤ data (the JET database as well as the proprietary Access information).
¤ However, the main point I'm trying to drive home here is that the DATA
¤ itself (not the forms, reports, queries, etc. that compliment the data) is
¤ stored in a JET Database that MS Access simply wraps and extends. The
¤ result is placed into an .mdb file. In this context, JET and Access are not
¤ the same thing.
¤

Nobody said they were. All that was stated is that the terms Jet and Access may both be used to
describe an Access database. But at the risk of repeating myself, the Access application is the only
one of the two that has full control over an .mdb file. The Jet Database Engine was created for
Microsoft Access and extended so that other development platforms could use it.

The next thing you know, well be arguing over whether to call Word and Excel documents "OLE
Structured Storage" files - because that is the underlying technology used. ;-)


Paul
~~~~
Microsoft MVP (Visual Basic)

[Scott M.]

Re: Access vs SQL

> ¤ As I've said, in many situations the term "Access Database" is just fine[color=blue]
> to
> ¤ convey the meaning of what you are trying to say. What we are
> discussing is
> ¤ completely different than those high level discussions (such as the ones
> ¤ returned by your search).
>
> No actually that was never the discussion. The discussion involved a
> response to
> aatcbbtccctc@ya hoo.com who claimed that an .mdb file is not an Access
> file.[/color]

No actually here is what aatcbbtccctc@ya hoo.com said:

"Access is *not* a database."

He didn't say that an .mdb is not an Access file. My comments here and
earlier have been part of the discussion..

Is Access = database or is .mdb=database?

Most of the time and in most situations it's fine to say yes beacuse we all
know what is trying to be said. But at low-levels it isn't correct to say
that Access is the database and the .mdb is the database. Access is a GUI
to BOTH the raw data as well as Access-specific data (reports, forms, VBA,
etc.). The raw data is stored in the JET database, which Access wraps.
[color=blue]
> ¤ Just because I use 2 words interchangeable doesn't mean that they are
> the
> ¤ same thing technically. For example, in the OO world, the terms
> "object"
> ¤ and "class" are often interchanged and for many discussions that's fine.
> ¤ But there is a world of difference between what an "object" actually is
> vs.
> ¤ what a "class" actually is.
> ¤
> ¤ The article I've provided is specifically about the low-level
> understanding
> ¤ of what JET actually is and it's relationship to Access.
>
> Don't think I follow where you are going with this.[/color]

Hmmm, the same place I've been all along :). Did you read the article?

[Paul Clement]

Re: Access vs SQL

On Fri, 15 Apr 2005 11:10:38 -0400, "Scott M." <s-mar@nospam.nosp am> wrote:

¤ > ¤ As I've said, in many situations the term "Access Database" is just fine
¤ > to
¤ > ¤ convey the meaning of what you are trying to say. What we are
¤ > discussing is
¤ > ¤ completely different than those high level discussions (such as the ones
¤ > ¤ returned by your search).
¤ >
¤ > No actually that was never the discussion. The discussion involved a
¤ > response to
¤ > aatcbbtccctc@ya hoo.com who claimed that an .mdb file is not an Access
¤ > file.
¤
¤ No actually here is what aatcbbtccctc@ya hoo.com said:
¤
¤ "Access is *not* a database."
¤
¤ He didn't say that an .mdb is not an Access file. My comments here and
¤ earlier have been part of the discussion..

Yes he did:
[color=blue][color=green]
>>[/color][/color]
I suspect your mistake is in believing that an MDB file is an *Access*
file. It is not - it is a *Jet* file, in which Access is able to store
its own things (in addition to the standard Jet things).
<<


¤ Most of the time and in most situations it's fine to say yes beacuse we all
¤ know what is trying to be said. But at low-levels it isn't correct to say
¤ that Access is the database and the .mdb is the database. Access is a GUI
¤ to BOTH the raw data as well as Access-specific data (reports, forms, VBA,
¤ etc.). The raw data is stored in the JET database, which Access wraps.
¤

For the last time...Access can operate on the database file directly. It is not a wrapper. Does Word
wrap a .doc file? Does Excel wrap an .xls file?

As I questioned in my other post, do we now call .doc and .xls OLE Structure Storage files instead
of Word and Excel files because that is the API which is employed?

¤ > ¤ Just because I use 2 words interchangeable doesn't mean that they are
¤ > the
¤ > ¤ same thing technically. For example, in the OO world, the terms
¤ > "object"
¤ > ¤ and "class" are often interchanged and for many discussions that's fine.
¤ > ¤ But there is a world of difference between what an "object" actually is
¤ > vs.
¤ > ¤ what a "class" actually is.
¤ > ¤
¤ > ¤ The article I've provided is specifically about the low-level
¤ > understanding
¤ > ¤ of what JET actually is and it's relationship to Access.
¤ >
¤ > Don't think I follow where you are going with this.
¤
¤ Hmmm, the same place I've been all along :). Did you read the article?
¤

You may want to consider other sources beyond that article. Especially if you're simply going to
ignore the fact that the Jet Database Engine provides only a subset of the functionality that is
supported for an Access database. That is a technical fact that cannot be disputed.


Paul
~~~~
Microsoft MVP (Visual Basic)