views:

184

answers:

3

I am attempting to move data from a recordset directly into an array. I know this is possible, but specifically I want to do this in VBA as this is being done in MS Access 2003.

Typically I would do something like the following to archive this:

Dim vaData As Variant 
Dim rst As ADODB.Recordset

' Pull data into recordset code here...

' Populate the array with the whole recordset.
vaData = rst.GetRows 

What differences exist between VB and VBA which makes this type of operation not work?

What about performance concerns? Is this an "expensive" operations?

+1  A: 

The usual reason that your sample would not work is that the proper library for ADO has not been referenced (Tools->References, Microsoft ActiveX Data Objects x.x Library), otherwise, it should be fine.

Remou
A: 

I agree it does look like it might be a reference problem.

If you are going to be sticking with access/jet then you might want to consider using DAO as all things being equal it will be faster then ADO. Here is a quick example

Public Sub Foo()
Dim aFoo As Variant
Dim db As DAO.Database
Dim rst As DAO.Recordset

Set db = DBEngine(0)(0)
Set rst = db.OpenRecordset("tblFoo")

With rst
    .MoveLast
    .MoveFirst
    aFoo = .GetRows(.RecordCount)
End With

rst.Close
db.Close

End Sub
Kevin Ross
+1  A: 

The following code works for me:

Dim rst           As ADODB.Recordset
Dim vDat          As Variant

Set rst = CurrentProject.Connection.Execute("select * from tblTemp4")
vDat = rst.GetRows

Do a debug-compile, as mentioned this could be ref issue. As noted, some perfer DAO, but keep in mind DAO requires you to do a movelast. ADO does not. These days, ADO or DAO really comes down to your preferance, and performance is rarely an issue. ADO tends to be a bit cleaner of a object model, but whatever your familer with is likey the best choice in most cases

Albert D. Kallal
DAO does not require a .MoveLast unless you want an accurate recordcount, which you hardly ever actually need (you only need to know if the recordset returned records and the recordcount is always 1 or more if the DAO recordset returned records). I see no reason to use ADO, which is DEAD, DEAD, DEAD. DAO is part of a live database engine that is under constant development, and seems to me to be the future for working with Jet/ACE data.
David-W-Fenton
I see now from looking testing GetRows that if you pass no parameter to it, it retrieves only one row. You could choose an arbitrarily large number and skip the .MoveLast and avoid the performance hit. Or you could get an accurate recordcount by checking the table's .RecordCount property, though that doesn't work on linked tables, so you'd have to use the back end directly (not all that difficult to code and surely much more efficient than a MoveLast on a large recordset), but it won't work on anything other than a single-table recordset.
David-W-Fenton