Using ADO in an mdb application

  • Thread starter Thread starter Bill Murphy
  • Start date Start date
DAO works faster than ADO

ROFL

MDB DOES NOT WORK

what part of that do you not understad?

how many times have you been pulled out of bed at 3am in order to go and fix
a FE / BE crap that doesn't print a report and a manufacturing company can't
keep the assembly line working?

how many times?

until you've got some real world experience, stfu kid

MDB is not reliable
and NO DAO is not faster for anything
 
I use ONE LIBRARY
and I use ONE DATABASE

and it's neither DAO nor MDB



how friggin DARE you say that DAO is faster?

MDB IS NOT AN OPTION, IT IS NOT FASTER DAO DOES NOT WORK BECAUSE MDB IS NOT
AN OPTION
 
seriously BOOB MORLEY

please explain to me-- where it's stated that I'm not allowed to say 'crap'

and please explain to me where you got your egocentric, ethnocentric
attitude problem

haven't you ever heard of ebonics, yo?

swearing it LEGAL now kid
 
why don't you go and take your DAO crap and build a time machine and go back
and play in the 90s

ADO is faster -BECAUSE- MDB is unacceptable

ADO isn't strong enough for a single user nor a single record
 
Actually, it was included in MDAC up to 2.6 (which is not 10 years old),
Office 2000 (which is not 10 years old), Office XP (which is not 10 years
old), Windows 2000 (which is not 10 years old), and I believe even Windows
XP (which is not 10 years old). So I did my math, how are you doing yours?

But regardless of that, the OP was talking about existing DAO code which he
is currently using, so it's relevant to this conversation no matter how you
look at it.

Your posts in this thread are strictly inflammatory, and not meant to be
helpful (as they almost always have been since I first saw your name), so
you'll find that I probably won't respond to many--if any--of them in the
future.



Rob
 
Bwahahaha...I don't need to say anything further; your post makes it plain
to everybody just what kind of person you are.


Rob
 
To Aaron Kempf,

My posting on 4/24 asking for help with ADO started this thread. The
postings by Robert, Tony and Mattias have been extremely helpful to me and
probably to others. They understand the purpose of the forums, helping
others. You apparently do not understand this. Your rantings and ravings
and personal attacks have been extremely unhelpful. They have no place in
these forums. A new user would certainly not be encouraged to return here
for help based on your postings.

Bill
 
I'm still not convinced... tell us how you really feel, Aaron...
You're comical.. thanks for the laugh.
 
I disagree, kid





Robert Morley said:
Actually, it was included in MDAC up to 2.6 (which is not 10 years old),
Office 2000 (which is not 10 years old), Office XP (which is not 10 years
old), Windows 2000 (which is not 10 years old), and I believe even Windows
XP (which is not 10 years old). So I did my math, how are you doing yours?

But regardless of that, the OP was talking about existing DAO code which he
is currently using, so it's relevant to this conversation no matter how you
look at it.

Your posts in this thread are strictly inflammatory, and not meant to be
helpful (as they almost always have been since I first saw your name), so
you'll find that I probably won't respond to many--if any--of them in the
future.



Rob
Click to expand...
 
he's not talking about 'DAO' he is talking about 'ADO'

if you want to be a DAO / MDB fanboy you can go and play in the corner.

this is an ADP newsgroup; if you say ANYTHING anti-ADP you will pay the
price
 
you have issues, don't you?

steve.

Aaron Kempf said:
he's not talking about 'DAO' he is talking about 'ADO'

if you want to be a DAO / MDB fanboy you can go and play in the corner.

this is an ADP newsgroup; if you say ANYTHING anti-ADP you will pay the
price
Click to expand...
 
http://msdn2.microsoft.com/en-us/library/ms810810.aspx

Deprecated MDAC Components
These components are still supported in the current release of MDAC, but
might be removed in future releases. Microsoft recommends that when you
develop new applications, you avoid using these components. Additionally,
when you upgrade or modify existing applications, remove any dependency on
these components.

Jet: Starting with version 2.6, MDAC no longer contains Jet components. In
other words, MDAC 2.6, 2.7, 2.8, and all future MDAC releases do not contain
Microsoft Jet, Microsoft Jet OLE DB Provider, or the ODBC Desktop Database
Drivers.
JRO: The Microsoft Jet OLE DB Provider and other related components have
been removed from the MDAC stack since MDAC 2.6. Jet Replication Objects
(JRO) is used only with Jet (Access) databases, basically to create or
compact the Jet Database and Jet Replication Management. JRO has been
deprecated and MDAC 2.7 will be its last release. It will not be available
on the 64-bit Windows operating system.


MDAC Releases
Here is a list of the supportability scenarios of past, present, and future
MDAC releases, starting with the earliest.

MDAC 1.5, MDAC 2.0, and MDAC 2.1: These versions of MDAC were independent
releases that were released through the Microsoft Windows NT® Option Pack,
the Microsoft Windows Platform SDK, or the MDAC Web site. These versions of
MDAC are no longer supported.
MDAC 2.5: This version of MDAC was included with the Windows 2000 operating
system. Future services packs of MDAC 2.5 will be included with
corresponding Windows 2000 service packs. Additionally, these MDAC services
packs will be released to the MDAC Web site in accordance with the Windows
2000 service pack release schedule. You can only install this version of
MDAC on Windows NT, Windows 95, and Windows 98 platforms. You can only
install this version on Windows 2000 and Windows Millennium Edition
platforms through the operating systems or their services packs. This
version is currently supported.
MDAC 2.6: MDAC 2.6 RTM, SP1, and SP2 were included with Microsoft SQL Server
2000 RTM, SP1, and SP2, respectively. Additionally, these MDAC service packs
were released to the MDAC Web site in accordance with the Microsoft SQL
Server 2000 service pack release schedule. You can install this version of
MDAC and its service packs on Windows 2000, Windows Millennium Edition,
Windows NT, Windows 95, and Windows 98 platforms. This version is no longer
supported.
MDAC 2.7: This version of MDAC is included with the Microsoft Windows XP RTM
and SP1 operating systems. You can install this version of MDAC and its
service packs on Windows 2000, Windows Millennium, Windows NT, and Windows
98 platforms. You can only install this version on the Windows XP platform
through the operating system or its services packs.
The 32-bit version of MDAC 2.7 has been released to the MDAC Web site.
The 64-bit version of MDAC 2.7 will release with the 64-bit version of
Windows XP only.
MDAC 2.8: This version of MDAC is included with Windows Server 2003 and
Windows XP SP2 and later.
The 32-bit version of MDAC 2.8 will also be released to the MDAC Web site at
the same time Windows Server 2003 is released to the customer.
The 64-bit version of MDAC 2.8 will release with the 64-bit version of
Windows Server 2003 only.

2.5
Maybe the original 2.5 has it.. Maybe not-- I don't know how we can tell.
of course I've updated to Windows 2000 SP4; so I've got MDAC 2.7-- which
'doesn't include JET right'?

2.6
This release does not include Microsoft Jet, the Microsoft Jet OLE DB
Provider or ODBC driver, the Desktop Database ODBC Drivers, or the Visual
FoxPro ODBC Driver.

2.7
This release does not include Microsoft Jet, the Microsoft Jet OLE DB
Provider, the Desktop Database Drivers ODBC Driver, or the Visual FoxPro
ODBC Driver.
2.8

This release does not include Microsoft Jet, the Microsoft Jet OLE DB
Provider or ODBC driver, the Desktop Database ODBC Drivers, or the Visual
FoxPro ODBC Driver.




**Microsoft Data Access Components (MDAC) 2.60.6526.3

This release does not include Microsoft Jet, the Microsoft Jet OLE DB
Provider, the Desktop Database Drivers ODBC Driver, or the Visual FoxPro
ODBC Driver.

**Office XP
Jet is not the default data access library, stick a fork in it

**Office 2003
Microsoft doesn't have MY PERMISSION to waffle on something like DAO vs ADO
vs DAO.. so I'll stick with their previous story that 'DAO/JET is going
away'.. So yeah-- I'm in militant denial about this crap

**Office 2007
Numerous improvements to ADO and ADP
NO NEW VERSION OF 'DAO' IT HAS BEEN RENAMED TO SOMETHING ELSE RIGHT?

**Windows 2000
of course I've updated to Windows 2000 SP4; so I've got MDAC 2.7-- which
'doesn't include JET right'?

**Windows XP
Who gives a crap about this artsy-fartsy crap? I'm a Windows 2000 User, XP
is for trendy dorks

**Windows Vista
THIS IS SUPPOSED TO HAVE WINFS; WHICH MEANS SQL SERVER-- AS A FILESYSTEM--
ON EVERY DESKTOP. DO YOU REALLY THINK THAT YOU'LL HOUSE MDB FILES _INSIDE_
OF SQL SERVER FOR DATABASE WORK? ROFL
 
screw you kid

'oh i want to use DAO'

DAO HAS BEEN DED FOR A DECADE KID
STFU and start talking to me with some respect
 
and I'm SOOOOOOO sorry that you're a little script kid that's scared of ADP


you should lose the training wheels, kid
 
Respect has to be earned. You've earned absolutely nothing with your
misbehavior on this forum. Don't expect any futher response from me, since
it's clear this would be a waste of my time or anyone's time.
 
it's not mis-behaivor

I'm the only one speaking the truth

JET and DAO haven't been included with Office, MDAC or WINDOWS for 10 years

STFU and read the facts, MDB WIMP
 
ADO is a wrapper around OLEDB.
OLEDB may be a wrapper around ODBC.

for example, if you use ADO on Access queries,
stored in an Access database, connected to linked
tables, you are using an OLEDB connection to JET,
which is using an ODBC connection to SQL Server.

or if you just use the ODBC provider to connect
to a database, then you are just using OLEDB as
a wrapper around ODBC.
 
1) Just to be clear, there is no performance advantage
to using ADO for queries that are stored in the mdb.
You have to move the stored queries/views/procedures
to the SQL Server, or use inline sql.

2) DAO transactions against ODBC are broken. (This is
undocumented) Using ADO does not fix this. If you have
DAO transactions, moving to stored procedures in the server
database would be a good idea.

(david)
 
Back
Top