VBA: Querying Access with Excel. Why so slow?
Solution 1
Lots of formulas may reference the query. Try temporarially turning on manual calculate in the macro and turning it off when all of your queries are done updating.
This should speed it up a bit, but still doesn't fix the underlying problem.
Solution 2
I'm no expert, but I run almost exactly the same code with good results. One difference is that I use the Command
object as well as the Connection
object. Where you
Set RST = Con.Execute(SQLQuery)
I
Dim cmd As ADODB.Command
Set cmd.ActiveConnection = con
cmd.CommandText = SQLQuery
Set RST = cmd.Execute
I don't know if or why that might help, but maybe it will? :-)
Solution 3
I don't think you are comparing like-with-like.
In Access, when you view a Query's dataview what happens is:
- an existing open connection is used (and kept open);
- a recordset is partially filled with the first few rows only (and kept open);
- the partial resultset is shown in a grid dedicated to the task and optimized for the native data access method Access employs (direct use of the Access Database Engine DLLs, probably).
In your VBA code:
- a new connection is opened (then later closed and released);
- the recordset is fully populated using all rows (then later closed and released);
- the entire resultset is read into a Excel's generic UI using non-native data access components.
I think the most significant point there is that the dataview in Access doesn't fetch the entire resultset until you ask it to, usually by navigating to the last row in the resultset. ADO will always fetch all rows in the resultset.
Second most significant would be the time taken to read the fetched rows (assuming a full resultset) into the UI element and the fact Excel's isn't optimized for the job.
Opening, closing and releasing connections and recordsets should be insignificant but are still a factor.
I think you need to do some timings on each step of the process to find the bottleneck. When comparing to Access, ensure you are getting a full resultset e.g. check the number of rows returned.
Solution 4
I used your code and pulled in a table of 38 columns and 63780 rows in less than 7 seconds - about what I'd expect - and smaller recordsets completed almost instantaneously.
Is this the kind of performance you are experiencing? If so, it is consistent with what I'd expect with an ADO connection from Excel to an MDB back-end.
If you are seeing much slower performance than this then there must be some local environment conditions that are affecting things.
Solution 5
I would recommend you to create the Recordset
explicitly rather than implicitly using the
Execute
method.
When creating explicitly you can set its CursorType and LockType properties which have impact on performance.
From what I see, you're loading data in Excel, then closing the recordset. You don't need to update, count records, etc... So my advice would be to create a Recordset
with CursorType = adOpenForwardOnly & LockType = adLockReadOnly
:
...
RST.Open SQLQuery, Con, adOpenForwardOnly, adLockReadOnly
Range(CellPaste).CopyFromRecordset RST
...
Dan
Updated on June 19, 2022Comments
-
Dan almost 2 years
I found this code online to query Access and input the data into excel (2003), but it is much slower than it should be:
Sub DataPull(SQLQuery, CellPaste) Dim Con As New ADODB.Connection Dim RST As New ADODB.Recordset Dim DBlocation As String, DBName As String Dim ContractingQuery As String If SQLQuery = "" Then Else DBName = Range("DBName") If Right(DBName, 4) <> ".mdb" Then DBName = DBName + ".mdb" DBlocation = ActiveWorkbook.Path If Right(DBlocation, 1) <> "\" Then DBlocation = DBlocation + "\" Con.ConnectionString = DBlocation + DBName Con.Provider = "Microsoft.Jet.OLEDB.4.0" Con.Open Set RST = Con.Execute(SQLQuery) Range(CellPaste).CopyFromRecordset RST Con.Close End If End Sub
The problem is that this code takes very long. If I open up Access and just run the query in there it takes about 1/10th the time. Is there anyway to speed this up? Or any reason this might be taking so long? All my queries are simple select queries with simple where statements and no joins. Even a
select * from [test]
query takes much longer than it should.EDIT: I should specify that the line
Range(CellPaste).CopyFromRecordset RST
was the one taking a long time.
-
Dan over 14 yearsThis is problematic because not everyone has DAO enabled so it'll make it harder to pass this file around to different people.
-
Dan over 14 yearsI gave this a try. It worked but did not lead to a difference in runtime. Thanks anyway.
-
JimmyPena over 14 yearsThe same could apply to ADO. My understanding is that DAO is part of, or closely related to, the Jet engine used by Access 2003. So it's highly unlikely that it wouldn't be present along with Access. But you can always check the following location for it: C:\Program Files\Common Files\Microsoft Shared\DAO\dao360.dll (assuming DAO 3.6) You would also need to convert your code to late bound, and only use the DAO code if the file was present.
-
David-W-Fenton over 14 yearsIt's also present with Excel, as the Jet db engine is a component of Office, and Excel is quite closely integrated with it.
-
onedaywhen over 14 yearsThe OP said, "the query in there it takes about 1/10th the time". You don't really think switching to DAO will yield a 1000% performance benefit, do you?
-
JimmyPena over 14 yearsNo, but all things being equal it will be faster.
-
onedaywhen over 14 years@JP: Maybe so (or maybe no significant increase) but that's a distraction from, rather than an solution to, the problem here.
-
JimmyPena over 14 yearsThe problem is that the code is slow. I'm suggesting another method that might be faster. Instead of taking his existing code for granted and trying to make micro-optimizations on it, an entirely new approach to his goal might yield faster results.