Using ADO in an mdb application

  • Thread starter Thread starter Bill Murphy
  • Start date Start date
stfu retards

you don't have 'less layers' then we do

single layer = OLEDB

stop spreading misinformation, kids
 
yeah.

Access Crashed Inconsistently

The client was PISSED and I didn't eat for months

of course, everyone at MS was sitting around driving their big fat BMW so
they dont' give a flying crap

next time I get someone at MSFT telling me that THEY WILL NOT FIX A BUG?
I don't know what I'll do

I'm just sick and friggin tired of Microsoft focusing on the XBox and Excel
Server and InfoPath and SharePoint-- and ignoring their core competencies

BUG FREE SOFTWARE IS MY DEMAND
 
Whatever...I'm tired of hearing your lies, rants, revisionist history, and
denigration. You're now on my Ignore list. Bye bye.


Rob
 
MY LIES?

wtf are you talking about?

I'm not the one spreading mis-information

I'm not the one that is WAFFLING on the future of MS Access.
and I'm not the one that is convincing newbies to go iinto a dead-end
database
 
I've never lied once in my life

revisionist history?

Just because MS killed MDB 10 years ago; you think that you can say that I'm
revisionist history?

JET AND DAO HAVE NOT BEEN INCLUDED WITH WINDOWS, MDAC OR OFFICE FOR A DECADE
 
good stuff

Access isn't a database; and it hasn't been for a decade

Access is a front end to SQL Server

File, New, Project (existing data)

anything else is depecrated
 
Robert,
Ignore this moron. I have seen him out here lately making statements about
Access and Jet that are completely incorrect. He seems to have some perverse
bias against Access and Jet.
His statements show his lack of knowledge on the subject and he is giving
very bad input on every post to which he responds.
 
completely incorrect?

bs kid

I'm sorry-- but I stand by the FACT that Windows, Office and MDAC haven't
included JET or DAO for a decade

try arguing with the FACTS kid
 
My larger point was DAO will work immensely faster with Access databases
than ADO will. Try any test you want, and DAO will almost always be faster.
Click to expand...

Perhaps I do not understand myself what the word means 'immensely'?

Here any test I want:

' ### Code start here ###
Option Explicit

Private Declare Function GetTickCount _
Lib "Kernel32" () As Long

Private Const CONN_STRING = _
"C:\db1.mdb"

Private Const SQL = _
"select ID from MillionRecords order by ID"

Sub main()
Dim i As Long
For i = 1 To 6
Debug.Print TestADO
Debug.Print TestDAO
Next
End Sub

Function TestADO() As String
Dim lTick As Long
Dim rs As ADOR.Recordset
Dim lValue As Long

Set rs = New ADOR.Recordset
With rs
.ActiveConnection = _
"Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data source=" & CONN_STRING
.Source = SQL
.CursorType = adOpenStatic
.LockType = adLockReadOnly
lTick = GetTickCount
.Open
.MoveLast
lValue = .Fields(0).Value
TestADO = "AD0=" & GetTickCount - lTick
.Close
End With
End Function

Function TestDAO() As String
Dim lTick As Long
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim lValue As Long

Set db = DBEngine.Workspaces(0).OpenDatabase( _
CONN_STRING, , True)
lTick = GetTickCount
Set rs = db.OpenRecordset(SQL, dbOpenSnapshot)
With rs
.MoveLast
lValue = .Fields(0).Value
TestDAO = "DAO=" & GetTickCount - lTick
.Close
End With
Set rs = Nothing
db.Close
Set db = Nothing
End Function

' ### Code end here ###

For me, the results:

AD0=6719
DAO=6579
AD0=6734
DAO=6485
AD0=6750
DAO=6156
AD0=7063
DAO=7125
AD0=6578
DAO=7062
AD0=6985
DAO=6062

For me, the results are not to be extremely different. And you?
 
"Please do not feed the Troll"

From: (e-mail address removed), on 5/4/2007 5:01 AM:
 
In this case, you're using "MoveLast", which jumps directly to the end of
the recordset. You're essentially measuring a single operation. Try
scrolling through every last record in the recordset (a more normal
operation in most circumstances), or performing an update to every record in
the recordset, and you will likely see substantially greater differences.



Rob
 
did you consider that SQL Server does a better job of indexing than MS
Access?

that is a key part of this argument

please give more info; I'll gladly share some of my results
All I know is that i've got 200 reports right now that each take 5 minutes

and in a week I rewrote them all to ADP and they're all sub-minute
 
additionally

with ADO you can write your layer to work against SQL relationally-- and
then you can rewrite queries to use analysis services

this is the trump card-- DAO has no place in any business in the year 2007
not when every vendor has a freeware solution
 
and also-- you've got to compare DAO w/ MDB against ADO and SQL Server

ADO against MDB is just plain stupid because ANY use of MDB is just plain
stupid
 
Robert Morley _IS_ the trolll
him and all the other MVP dorks around here?

they're all a bunch of worthless MDB kids
 
In this case, you're using "MoveLast", which jumps directly to the end of

That is not really true. Movelast fully populates the recordset, and
he has a snapshot, so each record in the recordset is fully populated.
There is no 'jumping' involved

However, you are correct that the example in not useful. Loading a
sorted recordset of 1 million records, then just discarding it, is
ridiculous.
Regardless of ADO or DAO, this is the absolute worst way to select
that record that I can think of. This example is really bad code. This
is a bad way to find a record. It is possible to imagine that there might
be a reason for not using a sensible select statement, or sensible ADO
and DAO methods in the ADO and DAO objects, but taken all
together it is just ridiculous.

So I agree with your conclusion: that example is the wrong recordset
with the wrong code, and no relation to anything an experienced person
would put into either an ADO application or a DAO application.

(david)
 
Back
Top