ms-access - microsoft - connection string access 2016

¿Por qué mi base de datos de Access no está actualizada cuando la leí de otro proceso?

Question

En mi aplicación, hago lo siguiente:

1. Abra una base de datos de Access (.mdb) usando Jet / ADO y VB6
2. Borrar y volver a llenar una tabla con nuevos datos
3. Cierre la base de datos
4. Inicie otro proceso que haga algo con los nuevos datos.

El problema es que a veces el segundo proceso no puede encontrar los nuevos datos. A veces, la tabla está vacía, a veces RecordCount> 0, pero EOF es verdadero y no puedo mover MoveFirst o MoveNext. En pocas palabras: todo tipo de cosas raras.

Mi solución actual es agregar un retraso entre el cierre de la base de datos y el inicio del segundo proceso.

• ¿Que está sucediendo aquí?
• ¿Puedo hacer algo al respecto? (Además de usar una base de datos diferente)

Answer 1

Dado que el primer proceso es el único proceso con MDB abierto, puede ser un poco vago para volver a escribir cosas en el archivo. Incluso después de que finaliza el proceso, puede haber un retraso mientras el sistema operativo vuelve a escribir las páginas pendientes y esto puede suceder después de que el proceso haya indicado que se ha completado.

Mi recomendación sería, dejar de usar Access, usar SQL Server 2008 Express en su lugar.

Answer 2

Este artículo de Microsoft Knowledge Base explica cómo hacerlo.

Aquí hay un extracto con código de muestra. El código utiliza dos conexiones de un proceso, por lo que debe extraer la parte de lectura en su segundo proceso.

1. El escritor debe iniciar una transacción, utilizando Connection.BeginTrans de ADO, antes de escribir los datos.
2. El escritor debe realizar las actualizaciones de la base de datos y luego confirmar la transacción (utilizando ADO Connection.CommitTrans).
3. El lector debe llamar a JRO.JetEngine.RefreshCache pasando su conexión antes de intentar leer los datos.

Tenga en cuenta que JRO.JetEngine se incluye al agregar una referencia a la biblioteca Microsoft Jet And Replication Objects 2.1 a su proyecto de VB.

    Sub SyncReadDemo()
    Dim conn1 As New ADODB.Connection
    Dim conn2 As New ADODB.Connection
    Dim rs As New ADODB.recordset
    Dim JRO As New JRO.JetEngine
    Dim strConnect As String
    Dim i As Long


  '' Set up our connection string (requires a database named c:/db1.mdb).
    strConnect = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=c:/db1.mdb"

    '' Open connection 1 and drop and re-create test table.
    conn1.CursorLocation = adUseServer
    conn1.Open strConnect
    On Error Resume Next
    conn1.Execute "drop table tmpTest", , _
        adExecuteNoRecords + adCmdText
    On Error GoTo 0
    conn1.Execute "create table tmpTest (id long)", , _
        adExecuteNoRecords + adCmdText

    '' Close connection 1 to flush the creation of table tmpTest. 
    conn1.Close

    '' Now open connection 1 and connection 2.
    conn1.Open strConnect
    conn2.Open strConnect

    '' Insert 10 records using connection 1.
    '' Note we must perform all writes inside of a transaction.
    conn1.BeginTrans
    For i = 1 To 10
        conn1.Execute "insert into tmpTest (id) values (1)", , _
            adExecuteNoRecords + adCmdText
    Next i
    conn1.CommitTrans

    '' Refresh cache for reader connection.
    JRO.RefreshCache conn2
    Set rs = conn2.Execute("select * from tmpTest", , adCmdText)

    '' Count records in our table (should be 10).
    i = 0
    While Not rs.EOF
        i = i + 1
        rs.MoveNext
    Wend
    rs.Close

    MsgBox "Read " & i & " records using different connections."

    conn1.Close
    conn2.Close

End Sub

Answer 3

Solo una conjetura, pero podría deberse al hecho de que el motor Jet presenta una memoria caché de lectura y escritura diferida:

Cómo implementar contadores personalizados multiusuario en Jet 4.0 y ADO 2.1

"Microsoft Jet tiene un caché de lectura que se actualiza cada milisegundos de PageTimeout (el valor predeterminado es 5000 ms = 5 segundos) .También tiene un mecanismo de escritura diferida que opera en un subproceso separado del procesamiento principal y escribe cambios en el disco de manera asíncrona. los mecanismos ayudan a aumentar el rendimiento, pero en ciertas situaciones que requieren alta concurrencia, pueden crear problemas ".

El artículo sugiere usar el método RefreshCache de Jet y configurar el Jet OLEDB: Modo de confirmación de transacción a 1 milisegundo (una ventaja para ADO sobre DAO para Jet es que puede modificar esta configuración sin cambiar el valor en el registro).

PD, debería considerar editar la base de datos de Access (.mdb) para mencionar ''Jet'' en su lugar y usar la etiqueta ''Jet'' también, de lo contrario recibirá un comentario de un cierto usuario de SO que es pernickety sobre estas cosas :)