2010-03-08 54 views
15

Estoy intentando mover datos de un conjunto de registros directamente a una matriz. Sé que esto es posible, pero específicamente quiero hacer esto en VBA ya que esto se está haciendo en MS Access 2003.Cómo rellenar una matriz con datos de conjunto de registros

Normalmente me haría algo como lo siguiente para lograr esto:

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 

¿Qué diferencias existir entre VB y VBA que hace que este tipo de operación no funcione?

¿Qué pasa con el rendimiento? ¿Es esto una operación "cara"?

+0

Un conjunto de registros es una matriz, y mucho más versátil que una matriz VBA (es decir, de referencia por nombre de columna y no sólo índice de la columna). ¿Por qué no usar el conjunto de registros directamente? He estado programando en VBA/DAO durante más de una década y nunca he usado GetRows. ¿Qué te hace pensar que lo necesitas? –

+0

Específicamente para minimizar el tiempo que la conexión a otros objetos ADODB está abierta. –

+2

¿Qué tal un conjunto de registros desconectado ADO, entonces? –

Respuesta

1

La razón habitual que su muestra no funcionaría es que la biblioteca adecuada para ADO no ha sido referenciado (Herramientas> Referencias, Microsoft ActiveX Data Objects x.x Biblioteca), de lo contrario, que debería estar bien.

0

Estoy de acuerdo que tiene un aspecto que podría ser un problema de referencia.

Si usted va a pegarse con acceso/chorro entonces es posible que desee considerar el uso de DAO como todas las cosas en igualdad de condiciones que será más rápido luego de ADO. Aquí está un ejemplo rápido

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 
16

El siguiente código funciona para mí:

Dim rst   As ADODB.Recordset 
Dim vDat   As Variant 

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

Haz una depuración-compilación, como se ha mencionado que esto podría ser cuestión de ref. Como se ha señalado, algunos DAO más lentos, pero tenga en cuenta que DAO requiere que haga un movelast. ADO no. En estos días, ADO o DAO realmente se reducen a su preferencia, y el rendimiento rara vez es un problema. ADO tiende a ser un poco más limpia de un modelo de objetos, pero lo que su familer se vería debilitada con la mejor opción en la mayoría de los casos

+0

DAO no requiere un .MoveLast a menos que desee un registro preciso, que casi nunca necesita realmente (solo necesita saber si el conjunto de registros devolvió registros y el registro es siempre 1 o más si el conjunto de registros DAO devolvió los registros). No veo ninguna razón para usar ADO, que está MUERTO, MUERTO, MUERTO. DAO es parte de un motor de base de datos en vivo que está en constante desarrollo, y me parece que es el futuro para trabajar con datos de Jet/ACE. –

+1

Veo ahora buscar pruebas en GetRows que si no le pasa ningún parámetro, recupera solo una fila. Puede elegir un número arbitrariamente grande y omitir .MoveLast y evitar el golpe de rendimiento. O puede obtener un registro preciso al verificar la tabla.La propiedad RecordCount, aunque eso no funciona en tablas vinculadas, por lo que tendría que usar el back-end directamente (no es tan difícil de codificar y seguramente mucho más eficiente que un MoveLast en un conjunto de registros grande), pero no lo hará trabajar en cualquier cosa que no sea un conjunto de registros de una sola tabla. –

+1

@ David-W-Fenton ADO no está MUERTO? Kettle llamando a la olla negra aquí ... – Robino

1

En Access que puede hacer un indexado buscan. Ese es hábilmente el método más rápido e incluso más rápido que buscar en matrices.

Set rs = CreateObject("ADODB.Recordset") 
    rs.CursorLocation = adUseServer 
    rs.Open "MyData", CurrentProject.Connection, , , adCmdTableDirect 
    rs.Index = "fieldX" 

    rs.Seek fieldXvalue 

Si solo recorre toda la tabla de una matriz realmente es la más rápida. Una excepción: en teoría, si tiene una clave principal numérica, puede establecer el índice en su posición exacta en la matriz, por lo que no puede encontrar rs.find o rs.seek, simplemente puede acceder a ella como una matriz (índice) y eso es REALMENTE rápido. No comparé con la búsqueda indexada, pero puede ser más rápido.

Cuestiones relacionadas