Synchronizing Data

Synchronizing two replicas involves exchanging data and design changes. Synchronization can be bi-directional, (that is, changes in each replica are propagated to the other) or can occur in a single direction.

The following listing demonstrates how to synchronize changes between two replicas. The first example shows how to do a direct, two-way synchronization.

DAO

Sub DAOTwoWayDirectSync()

   Dim dbsNorthwind As DAO.Database

   Set dbsNorthwind = DBEngine.OpenDatabase(".\NorthWind.mdb")

   ' Sends changes made in each replica to the other.

   dbsNorthwind.Synchronize ".\FY96.mdb", dbRepImpExpChanges

   dbsNorthwind.Close

End Sub

JRO

Sub JROTwoWayDirectSync()

   Dim repMaster As New JRO.Replica

   repMaster.ActiveConnection = ".\NorthWind.mdb"

   ' Sends changes made in each replica to the other.

   repMaster.Synchronize ".\FY96.mdb", jrSyncTypeImpExp, _

      jrSyncModeDirect

   Set repMaster = Nothing

End Sub

The following example shows how to do a two-way synchronization over the Internet.

DAO

Sub DAOInternetSync()

   Dim dbsTemp As DAO.Database

   Set dbsTemp = DBEngine.OpenDatabase(".\NewNorthWind.mdb")

   ' Synchronize the local database with the replica on

   ' the Internet server.

   dbsTemp.Synchronize "sampleserver/files/Northwind.mdb", _

      dbRepImpExpChanges + dbRepSyncInternet

   dbsTemp.Close

End Sub

JRO

Sub JROInternetSync()

   Dim repMaster As New JRO.Replica

   repMaster.ActiveConnection = ".\NorthWind.mdb"

   ' Synchronize the local database with the replica on

   ' the Internet server.

   repMaster.Synchronize "sampleserver/files/Northwind.mdb", _

      jrSyncTypeImpExp, jrSyncModeInternet

   Set repMaster = Nothing

End Sub

For more information on Internet synchronization, read the technical article "Internet Synchronization with Microsoft Jet 4.0" available on the Microsoft Developer Network (MSDN) Library.

The JRO and DAO code for performing a two way, direct synchronization between two replicas is similar. However, note that the JRO Synchronize method has an additional parameter that specifies jrSyncModeDirect. For functionality equivalent to DAO you must specify jrSyncModeDirect when calling the Synchronize method. In JRO, if the SyncMode parameter is omitted, the synchronization will be performed indirectly. The ability to perform indirect synchronizations is a new feature in JRO designed to increase performance when synchronizing over a Wide Area Network (WAN). See the section, "New Features in JRO" for more information about performing indirect synchronizations.

The following table shows the mapping between the DAO Exchange parameter of the Synchronize method and the JRO SyncType and SyncMode parameters.

DAO Parameter	DAO Constant	JRO Parameter	JRO Constant
Exchange	dbRepExportChanges	SyncType	jrSyncTypeExport
Exchange	dbRepImportChanges	SyncType	jrSyncTypeImport
Exchange	dbRepImExpChanges	SyncType	jrSyncTypeImpExp
Exchange	dbRepSyncInternet	SyncMode	jrSyncModeInternet

Listing Synchronization Conflict Tables

If two users at two separate replicas each make a change to the same record in the database, a conflict may occur. If changes are being tracked at the row level, a conflict will occur if two users make a change to the same record. If changes are being tracked at the column level, a conflict will occur if two users make a change to the same column with a record. When a conflict occurs, the changes made by one user will fail to be applied to the other replica. Information regarding the conflict will be replicated to both replicas.

Information about the conflict is contained in a conflict table in each replica. Conflict tables contain the information that would have been placed in the table if the change had been successful. You can examine these conflict tables and work through them row by row, resolving the conflicts as appropriate.

The following listings demonstrate how to determine whether conflicts occurred during synchronization and, if conflicts did occur, how to retrieve the names of the conflict tables that were created.

DAO

Sub DAOConflictTables()

   Dim dbsNorthwind As DAO.Database

   Dim tdfTest As DAO.TableDef

   Dim bConflict As Boolean

   Set dbsNorthwind = DBEngine.OpenDatabase(".\NorthWind.mdb")

   bConflict = False

   ' Enumerate TableDefs collection and check ConflictTable

   ' property of each.

   For Each tdfTest In dbsNorthwind.TableDefs

      If tdfTest.ConflictTable <> "" Then

         ' There was a conflict with this table

         Debug.Print tdfTest.Name & " had a conflict."

         bConflict = True

      End If

   Next tdfTest

   ' If bConflict is still false then we didn't find any

   ' tables that had conflicts.

   If Not bConflict Then Debug.Print "No conflicts."

   dbsNorthwind.Close

End Sub

JRO

Sub JROConflictTables()

   Dim repMaster As New JRO.Replica

   Dim rstConflicts As ADODB.Recordset

   repMaster.ActiveConnection = ".\NorthWind.mdb"

   Set rstConflicts = repMaster.ConflictTables

   If rstConflicts.BOF And rstConflicts.EOF Then

      ' There are no conflict tables so no conflicts occurred.

      Debug.Print "No conflicts."

   Else

      Do Until rstConflicts.EOF

         Debug.Print rstConflicts.Fields(0) & " had a conflict."

         rstConflicts.MoveNext

      Loop

   End If

End Sub

With JRO, the ConflictTables property of the Replica object is used to determine which tables had conflicts. This property returns an ADO Recordset object that contains one row for each table containing conflicts. With the ConflictTables property it is easy to determine whether or not conflicts occurred. If the Recordset is empty (the BOF and EOF properties of the Recordset are both true), then no errors occurred. This differs from DAO in that with DAO you must check the ConflictTable property for each table in the TableDefs collection to determine whether conflicts occurred and what the name of the related conflict table is.