Access vs SQL

[Cor Ligthert]

-----> Before you write next time something, look than at least at the
topic.

Cor, the last several times you have replied to my comments in other
threads, you have come back at me with cryptic responses like this one.
What are you trying to say? I have read this thread and my posts are very
clear on what I'm saying. Your posts, on the other hand, are
contradictory and confusing.

We are talking about the use of Access vs SQL (server) in this thread, look
at the subject of all the messages.

For me did you not notice that, because that is what you wrote. It does
really not give me much believe that you did read this message thread.

Cor

 

[Scott M.]

LOL!!!

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.

 

[Cor Ligthert]

Scott,

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.

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.

Access does not implement any db security (beyond a db password)

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

 

[Scott M.]

It's clear Cor that English isn't your first language (not trying to insult
you, just stating a fact). And, it's clear that you haven't been reading or
writing your English very well also.

Let's go back and "check" the thread as you suggest:

There were seven (7) messages on the "Access is or isn't a database" topic
involving three (3) other people BESIDES myself BEFORE I said anything about
Access and JET.

Yes, I did say "Access does not implement any db security (beyond a db
password)", but that doesn't automatically mean that Access is a database at
all. It simply means that Access implements a password on the JET database.
Are you really telling me that you couldn't put that together yourself?

You confuse me to no end Cor, because you write such off the wall things.
You constantly contradict yourself and state things that were never said by
anyone as if they were said by me and then deny things that were said by
yourself.

You are really telling me that you don't understand the concept of a thread
that breaks off into a sub-thread about a different twist on the original
post?

Seriously?

And are you seriously telling me that you can't separate something that was
said in one thread (when the term Access is used to refer to BOTH the
product and the data as I stated in my earlier post that I guess you didn't
read) from something that was said in a sub-thread (when we were discussing
this on a more technical level where Access is NOT used to describe BOTH the
product and the data)?

If my posts confuse you, my desire to have you clarify yourself bothers you
and my asking that you not go on babbling about un-related and non-factual
information bothers you so, please feel free to filter me from your NG
reader.

You are constantly telling me to go back and read the thread, but it is you
who isn't reading (or understanding) what is being said and is coming up
with non-sensical statements. It's very clear what I am saying, to whom I
said it and when, here's the summary:

Access is not as good as SQL for concurrent users.
Access does not support Stored Procedures to the extent that SQL does.
Access does not support the same level of security that SQL does.
Access is a product that wraps a JET database and extends it's UI via VBA,
Forms, Queries and Reports.

This is pretty darn clear Cor and it is almost identical to what I've said
in the previous posts. You may not agree (and I respect your right to do
so), but you seem to be the only one who doesn't, at least, understand what
I'm saying.

 

[Scott M.]

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

From:

http://www.microsoft.com/resources/documentation/sql/7/all/proddocs/en-us/msjet/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++®. "

 

[Scott M.]

Here's even more from that same article:

"Microsoft Access Users When you create an object through DAO by using
Microsoft Jet, only the standard built-in properties are created in the new
object's Properties collection. However, when Microsoft Access creates a
Microsoft Jet object, it may add several user-defined properties to objects.
These properties are a special case of user-defined properties known as
application-defined properties. For example, when you create a table in the
Microsoft Access user interface, and type a value in the Description field,
it automatically adds a new property to the TableDef object to represent the
description."

Notice how they refer to Access, not as the database, but as the "Microsoft
Access user interface"?

Notice how they talk about MS Access creating a "Microsoft Jet object"?

And, if you read the whole article, you'll see them talk about the actual
database being one of the DAO objects and that the DAO objects are APIs to
JET objects.

Is this clear enough for you?

 

[lgbjr]

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

 

[Scott M.]

You are on the right path Lee. Good luck!

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

 

[Paul Clement]

¤ > 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={Microsoft Access Driver (*.mdb)};" & _
"Dbq=c:\somepath\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]

¤ From:
¤
¤ http://www.microsoft.com/resources/documentation/sql/7/all/proddocs/en-us/msjet/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.]

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

 

[Scott M.]

¤ Tell me, what is the connection string in ADO or ADO.NET to connect to an
¤ .mdb file?

oConn.Open "Driver={Microsoft Access Driver (*.mdb)};" & _
"Dbq=c:\somepath\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 "satisfactory" connection string, while the actual DB
provider is "Microsoft.OLEDB.JET.n.x" as seen in the more commonly used:

Con.Open "Provider=Microsoft.JET.OLEDB.4.0.;Data Source=path"

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

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]

¤ ¤ Tell me, what is the connection string in ADO or ADO.NET to connect to an
¤ ¤ .mdb file?
¤ >
¤ > oConn.Open "Driver={Microsoft Access Driver (*.mdb)};" & _
¤ > "Dbq=c:\somepath\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 "satisfactory" connection string, while the actual DB
¤ provider is "Microsoft.OLEDB.JET.n.x" as seen in the more commonly used:
¤
¤ Con.Open "Provider=Microsoft.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]

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