Acelere esta operación de búsqueda/filtro-(base de datos VB6, TextFile, ADO, VFP 6.0)

text-files visual-foxpro

Question

Estoy tratando de descubrir cómo acelerar esta operación. Antes de importar un registro desde el archivo de texto, primero necesito ver si existe uno en la base de datos. Si existe, voy a realizar una operación de actualización en él. Si no existe voy a crear un nuevo registro.

Ejecutar el código que se ve debajo de esta operación toma alrededor de 3 horas.

Intenté usar el método de búsqueda de ADO y, de hecho, parece ser más lento que el método de filtro.

La base de datos es una base de datos Visual Foxpro 6. La tabla tiene un índice en el campo item_cd, pero la tabla no tiene ninguna clave principal establecida. Esto está fuera de mi control ya que no escribí el software y estoy tratando de evitar realizar cambios estructurales en la base de datos.

Hay 46652 filas en el archivo de texto y aproximadamente 650,000 registros / filas en el conjunto de registros ADO. Creo que adelgazar el conjunto de registros sería el mayor paso para solucionarlo, pero no he encontrado ninguna forma de hacerlo. Estoy tratando de evitar la creación de registros duplicados ya que no hay una clave principal, así que realmente necesito tener toda la tabla en mi conjunto de registros.

Debido a que estoy ejecutando esto en mi máquina local, parece que la operación está limitada por la potencia de la CPU. En realidad, esto podría usarse en toda la red, especialmente si puedo hacerlo más rápido.

Dim sFileToImport As String
sFileToImport = Me.lstFiles.Text
If sFileToImport = "" Then
MsgBox "You must select a file from the listbox to import."
Exit Sub
End If
If fConnectToDatabase = False Then Exit Sub
With gXRst
.CursorLocation = adUseClient
.CursorType = adOpenKeyset
.LockType = adLockReadOnly
.Open "SELECT item_cd FROM xmsalinv ORDER BY item_cd ASC", gXCon
End With
Call fStartProgress("Running speed test.")
Dim rstTxtFile As ADODB.Recordset
Set rstTxtFile = New ADODB.Recordset
Dim con As ADODB.Connection
Set con = New ADODB.Connection
Dim sConString As String, sSQL As String
Dim lRecCount As Long, l As Long
Dim s As String
sConString = "DRIVER={Microsoft Text Driver (*.txt; *.csv)};Dbq=" & gsImportFolderPath & ";Extensions=asc,csv,tab,txt;Persist Security Info=False;"
con.Open sConString
sSQL = "SELECT * FROM [" & sFileToImport & "]"
rstTxtFile.Open sSQL, con, adOpenKeyset, adLockPessimistic
If Not (rstTxtFile.EOF And rstTxtFile.BOF) = True Then
rstTxtFile.MoveFirst
lRecCount = rstTxtFile.RecordCount
Do Until rstTxtFile.EOF = True
''This code appears to actually be slower than the filter method I''m now using
''gXRst.MoveFirst
''gXRst.Find "item_cd = ''" & fPQ(Trim(rstTxtFile(0))) & "''"
gXRst.Filter = "item_cd = ''" & fPQ(Trim(rstTxtFile(0))) & "''"
If Not (gXRst.EOF And gXRst.BOF) = True Then
s = "Item Found - " & Trim(rstTxtFile(0)) ''item found
Else
s = "Item Not Found - " & Trim(rstTxtFile(0)) ''Item not found found
End If
l = l + 1
Call subProgress(l, lRecCount, s)
rstTxtFile.MoveNext
Loop
End If
Call fEndProgress("Finished running speed test.")
Cleanup:
rstTxtFile.Close
Set rstTxtFile = Nothing
gXRst.Close

Answer 1

En respuesta a la publicación de Bob Riemersma, el archivo de texto no está causando los problemas de velocidad. Cambié mi código para abrir un conjunto de registros con una consulta que busca un solo elemento. Este código ahora se ejecuta en 1 minuto y 2 segundos, en comparación con las tres o cuatro horas que estuve mirando hacia otro lado.

Dim sFileToImport As String
sFileToImport = Me.lstFiles.Text
If sFileToImport = "" Then
MsgBox "You must select a file from the listbox to import."
Exit Sub
End If
If fConnectToDatabase = False Then Exit Sub
Call fStartProgress("Running speed test.")
Dim rstTxtFile As ADODB.Recordset
Set rstTxtFile = New ADODB.Recordset
Dim con As ADODB.Connection
Set con = New ADODB.Connection
Dim sConString As String, sSQL As String
Dim lRecCount As Long, l As Long
Dim sngQty As Single, sItemCat As String
sConString = "DRIVER={Microsoft Text Driver (*.txt; *.csv)};Dbq=" & gsImportFolderPath & ";Extensions=asc,csv,tab,txt;Persist Security Info=False;"
con.Open sConString
sSQL = "SELECT * FROM [" & sFileToImport & "]"
rstTxtFile.Open sSQL, con, adOpenKeyset, adLockPessimistic
If Not (rstTxtFile.EOF And rstTxtFile.BOF) = True Then
rstTxtFile.MoveFirst
lRecCount = rstTxtFile.RecordCount
Do Until rstTxtFile.EOF = True
l = l + 1
sItemCat = fItemCat(Trim(rstTxtFile(0)))
If sItemCat <> "[item not found]" Then
sngQty = fItemQty(Trim(rstTxtFile(0)))
End If
Call subProgress(l, lRecCount, sngQty & " - " & sItemCat & " - " & rstTxtFile(0))
sngQty = 0
rstTxtFile.MoveNext
Loop
End If
Call fEndProgress("Finished running speed test.")
Cleanup:
rstTxtFile.Close
Set rstTxtFile = Nothing

Mis funciones:

Private Function fItemCat(sItem_cd As String) As String
''Returns blank if nothing found
If sItem_cd <> "" Then
With gXRstFind
.CursorLocation = adUseClient
.CursorType = adOpenKeyset
.LockType = adLockReadOnly
.Open "SELECT item_cd, ccategory FROM xmsalinv WHERE item_cd = ''" & fPQ(sItem_cd) & "''", gXCon
End With
If Not (gXRstFind.EOF And gXRstFind.BOF) = True Then
''An item can technically have a blank category although it never should have
If gXRstFind!ccategory = "" Then
fItemCat = "[blank]"
Else
fItemCat = gXRstFind!ccategory
End If
Else
fItemCat = "[item not found]"
End If
gXRstFind.Close
End If
End Function
Private Function fIsStockItem(sItem_cd As String, Optional bConsiderItemsInStockAsStockItems As Boolean = False) As Boolean
If sItem_cd <> "" Then
With gXRstFind
.CursorLocation = adUseClient
.CursorType = adOpenKeyset
.LockType = adLockReadOnly
.Open "SELECT item_cd, bal_qty, sug_qty FROM xmsalinv WHERE item_cd = ''" & fPQ(sItem_cd) & "''", gXCon
End With
If Not (gXRstFind.EOF And gXRstFind.BOF) = True Then
If gXRstFind!sug_qty > 0 Then
fIsStockItem = True
Else
If bConsiderItemsInStockAsStockItems = True Then
If gXRstFind!bal_qty > 0 Then
fIsStockItem = True
End If
End If
End If
End If
gXRstFind.Close
End If
End Function
Private Function fItemQty(sItem_cd As String) As Single
''Returns 0 if nothing found
If sItem_cd <> "" Then
With gXRstFind
.CursorLocation = adUseClient
.CursorType = adOpenKeyset
.LockType = adLockReadOnly
.Open "SELECT item_cd, bal_qty FROM xmsalinv WHERE item_cd = ''" & fPQ(sItem_cd) & "''", gXCon
End With
If Not (gXRstFind.EOF And gXRstFind.BOF) = True Then
fItemQty = CSng(gXRstFind!bal_qty)
End If
gXRstFind.Close
End If
End Function

Answer 2

Utilice un cursor firehose para los resultados de la consulta de VFP si no es así, y consulte su otra publicación aquí para obtener sugerencias sobre el conjunto de registros de archivo de texto.

Sin embargo, tal vez aún mejor, podrías intentar deshacerte de tu lento enfoque de "bucle y búsqueda".

Probablemente crearía un MDB Jet 4.0 temporal desde cero para cada archivo de texto que quiera buscar. Importe los datos de texto, indexe su campo clave. Use ADOX para definir una tabla vinculada en la base de datos de VFP. El uso de una consulta para hacer su coincidencia.

Cierre y deseche el MDB después.

Answer 3

Primero, intente crear un índice en memoria en item_cd con gXRst!item_cd.Properties("OPTIMIZE").Value = True que acelerará tanto Find como Filter .

Para obtener la máxima velocidad en la búsqueda, inicialice el índice de ayudante Collection como esta

Set cIndex = New Collection
On Error Resume Next
Do While Not gXRst.EOF
cIndex.Add gXRst.Bookmark, "#" & gXRst!item_cd.Value
gXRst.MoveNext
Loop
On Error GoTo ErrorHandler

E insertada de Find usa alguna función como esta

Public Function SearchCollection(Col As Object, Index As Variant) As Boolean
On Error Resume Next
IsObject Col(Index)
SearchCollection = (Err.Number = 0)
On Error GoTo 0
End Function

Answer 4

Una solución simple para acelerar la respuesta de Yours_Rs.find es usar primero la declaración Yours_Rs.move si es posible para usted. Lo que he hecho es usar la declaración MyRs.move antes de usar MyRs.find para acercarme a mi registro actual. Realmente me había funcionado ya que la respuesta de move statement es bastante enérgica.

Lo estaba usando para ubicar un registro de paciente. Por lo tanto, al mover el puntero a un registro cerca del registro real, la instrucción MyRs.find funciona con la velocidad de la luz.

Saludos,

MAS.

Answer 5

no responde su pregunta y este es un hilo muy antiguo, pero ¿por qué no importa su archivo de texto a una tabla temporal en su base de datos y luego hace una combinación? algo así como SELECT tt. * FROM texttemp tt left outer join xmsalinv xal en tt.field1 = xal.item_cd donde xal.item_cd es nulo

esto debería devolver el contenido de su archivo de texto importado que no tiene ninguna coincidencia item_cd en la base de datos, ya que se trata de un archivo de texto que complica la consulta y es por eso que me pregunto si no va a importar el contenido a un archivo temporal mesa.

ahora suponiendo que conozca el mapeo de los campos, probablemente también pueda usar esto para insertar asumiendo que su base de datos acepte insertar notación de selección que sería insertar en xmsalinv (campos) seleccionar (campos coincidentes) desde (como arriba ...) esto se mueve su estrangulamiento apunta al proceso de importación, que espero sea rápido.

las colecciones de ado parecen ser bastante estúpidas, por lo que no se benefician de ningún tipo de conocimiento sobre los datos y son un poco lentos.

ah siguiente artículo en "filtro vb6" google http://www.techrepublic.com/article/why-ados-find-method-is-the-devil/1045830

esta respuesta se basa en conocimientos básicos de sql y no está adaptada a foxpro

Answer 6

3 horas solo por unos cientos de miles de discos !!! Lo estás haciendo de la manera incorrecta. Simplemente: -aplique el archivo de texto en una tabla de VFP, luego inserte los que no existen en la tabla existente con un único SQL y actualice los que existen con otra actualización de SQL.

Eso es todo y debería tomar menos de un minuto (un minuto es incluso muy lento). Puede hacer todo esto usando el controlador VFPOLEDB y no importa que tenga una base de datos VFP6, VFPOLEDB tiene el motor VFP9 incorporado.