Document #509, Troubleshooting GoldMine® 4.0 Synchronization
Note: This document is intended for use by someone already familiar
with Synchronization. Some operations suggested in this document are outside
of the normal scope of general GoldMine knowledge. It may become necessary
to seek the assistance of your network administrator or an Authorized GoldMine
Solutions Partner.
The Front Range Solutions Sales Department can give you the
name of an Authorized GoldMine Solutions Partner in your area who should
be able to perform such operations. Contact the Front Range Solutions Sales
Department at 800.654.3526.
General Troubleshooting Strategy
The first step in solving any synchronization problem is determining at which point in the synchronization process the problem is occurring. The three main steps in the synchronization process are: the creation of the transfer set, the transferal of the transfer set from Point A to Point B, the retrieval of the data from the transfer set. The questions that need to be answered are as follows:
Did the transfer set get created successfully?
If the transfer set creation is not successful, then nothing will synchronize. There are two known reasons why transfer sets are not created successfully. First, a BDE error may have occurred – indicating either a problem with the database files or a hardware problem. (Note: Some database errors can only be viewed in the detail logs and may not be evident without some investigation.) Secondly, GoldSync may not be configured properly to generate transfer sets. This is most likely the case if no error messages were encountered, but the transfer set was not successfully built.
Were the changed records included in the transfer set?
During transfer set creation, if logging is enabled in the Process' options, the count of records added from each file is displayed in the process monitor and is entered into the detail logs. If it is reported that history records are not synchronizing and, upon examination of the logs, you see that no history records were added to the transfer set, we can assume that this is the problem. If the logs show that records of the appropriate type were added to the transfer set, then the contents of the transfer set can be examined in more detail by using the Sync the file Wizard to uncompress. This will unpack the transfer set show the different database files contained within the transfer set. If the record(s) in question are not in the transfer set, then you must determine whether the records should have been included in the transfer set according to the options set on the system creating the file. Were the changes within the cutoff date? Was a filter excluding the records? Were Tlog records present and valid?
Was a connection established with the remote?
Of course a connection to the remote is only necessary if you are using a connected method of synchronization. However, the non-connected methods can require other types of connections: POP3/SMTP servers, WAN drives, etc… Careful examination of the connection logs and/or process monitor can yield more information about problems encountered during the connection phase. If the connection was not attempted at all, then the problem is most likely a configuration issue. If the site is configured properly, then the problem may be an environmental problem rather than a GoldMine problem
(Modem problem, network problem, etc…)
Was the file transfer successful?
Regardless of the transport method you selected, the transfer set must be successfully delivered to the remote. If the transfer is failing consistently, steps must be taken to improve the quality of the connection. These steps depend on the type connection you are using.
Did the remote successfully retrieve the transfer set?
Once the transfer set is successfully sent to the remote, the transfer set must be successfully decrypted, uncompressed, and retrieved. If the decryption fails, it may be because different versions of GoldMine were used, or there were differing connection passwords. The uncompression process can fail because of multiple or out-dated versions of the
DZIP/DUNZIP DLL’s (both DZIP32.DLL and DUNZIP32.DLL should be dated 12/5/97) or because GoldMine/GoldSync cannot locate them because of an incorrect SYSDIR= setting in the GM.INI. Once the actual retrieval begins, each record retrieved is shown in the GoldMine Files logs or Contact Files logs. Assuming that the retrieval options and/or retrieve filter are not limiting the retrieval, and the record was not retrieved, then perhaps a more recent Tlog record already exists in the database or a 'zzzDel' Tlog exists for the record. (Note: 'zzzDel' orders take priority over any other type of change, even if the deletion order happened before the change to the record.) The retrieval is based on the Tlog records, so there may be Tlog records that exist for a record that is not currently in the database. This situation most commonly occurs for deleted records. If orphaned Tlogs are causing problems, they must be removed manually using a database browser such as BR4 available from Redstone Softbase Company at: http://www.redstonesoftbase.com/
Common Problems:
Data not synchronizing
When troubleshooting a problem where the synchronization process appears to complete successfully, however, changed records were apparently not transferred to the remote system; there are several things to check.
First, find a sample record that was modified on the host system but did not sync to the remote. Check whether the record in question was included in the transfer set. To determine this, check the logs (process monitor or sync logs) and check if there are records from the proper table included.
If the example record was a Contact1 record and the logs show that no Contact1 records were added, this is the problem. If the logs show some Contact1 records being included in the transfer set, then you can investigate further by uncompressing the transfer set using the sync wizard, and then examining the contents of the CONTACT1 file using BR4 or another database browser.
If the record is not in the transfer set, then the problem is occurring on the sending system. The most common reasons that a record would not go into a transfer set are based on the cutoff date, send options, or filters. There may also be a problem with the Tlogs. You can check the send options and filters very easily in the GoldSync site. To check the cutoff date you must know when the record in question was modified. To determine this you may use the SyncSpy utility available from the GoldMine Files Library at: ftp://ftp.goldminesw.com/public/utility/syncspy.exe. The Tlog records can be viewed manually with a utility like BR4, but it can be a time consuming and difficult process.
SyncSpy will tell you, for a specific record, when the change was made and who made it. The SYNCSTAMP date is the date used by GoldMine when placing records into a transfer set. Be sure that when using SyncSpy, you are viewing the SYNCSTAMP and not the LOGSTAMP. Once you know the date/time that the record was modified, you can determine whether the cutoff date used caused the record to not be sent.
Once you know that the record was successfully placed in the transfer set, you can check the retrieval process to see if the record was retrieved. Just as during the creation process, the first step is to check the process monitor or sync logs to determine whether records from that table were retrieved. Notice in Fig 1. That no records were retrieved from the CONTHIST table.
Clicking on the
Clipboard icon will toggle the viewing of the logs in the lower half of the
Process monitor. You may also notice that there were some records that showed
as "Skipped", this indicates changes that did not require processing
because the record/field was modified more recently in the target database than
in the transfer set. You can verify this with SyncSpy as well. However,
this time you will be comparing LOGSTAMPs rather than SYNCSTAMPs, because the
LOGSTAMP shows the modification date/time, which is used during the retrieval
process.
If the record does not appear in the target database, but still is not retrieved from the transfer set, then the record may have been deleted from the target database. Once a record is deleted from a database, the 'zzzDel' Tlog remains in the database and will prevent the deleted record from being re-added to the database. Since only the Tlog record remains from the deleted record, the only way to remove the Tlog is by using BR4 or some other database browser and finding the RECID of the deleted record in the transfer set and then removing the 'zzzDel' Tlog from the target database.
You can verify that this is the problem by retrieving the transfer set into an empty database first. If the record can be retrieved into an empty database, but is skipped when attempting to retrieve to your normal database, then the problem is most likely that it was a deleted record.
Recovering From a GoldBox Import
GoldMine Technical support has discovered a problem that has caused some customers to experience anomalies during synchronization where records imported by GoldBox may not properly synchronize. If GoldBox’s import procedure is prematurely aborted at the time of import, it has been observed that GoldBox creates RECIDs with the first few characters being specified by GoldBox as ‘CONTACT’, ‘CONTSUPP’ (or other invalid information) instead of an appropriately encrypted time/date stamp. In this case, GoldMine/GoldSync would evaluate the word (such as ‘CONTACT’) as a time/date stamp according to its algorithm and identify that record as having been changed on a specific date, at a specific time in the year 2007! This record would obviously not normally be included in transfer sets. To correct this problem, someone comfortable with extensive file manipulation and very familiar with
GoldMine/GoldSync should refer to Document # 517 on Replacing Corrupted RECID’s after an Import using GoldBox for exact steps that can be taken.
Note: Redstone SoftBase Company has corrected the issue outlined in this document and it is strongly recommended that an upgrade to the latest version of GoldBox be performed prior to importing with GoldBox. Redstone SoftBase can be contacted at 310.441.0782, redstone@earthlink.net, or http://www.redstonesoftbase.com for more information on upgrading to a current version of GoldBox. Upgrading to the current version of GoldBox may avoid the issue outlined in this document entirely.
Manually Copying Data
Copying data files from one system to another by using DOS or the Windows Explorer as a substitute for the Synchronization process is not recommended (or supported) by GoldMine Technical Support. Doing this will severely inhibit the synchronization process, as described below:
When a new record is added to a GoldMine database file, an entry is added in the appropriate Tlog with a value of zzNew. This entry specifies that the information in question has not yet been synchronized with a remote site nor has it been included into a transfer set. Since it is a new record that has not yet been synchronized, GoldMine will not track changes made to this record at the field level. It will simply synchronize the record at the record level.
If the database files are directly copied over, when synchronization takes place between the two systems the receiving system will compare the Tlogs and find that the record in question is a new record created locally at the exact same time and date as the record coming in via the transfer set. Consequently, the system will ignore the record because it already exists.
Instead of manually copying data from one system to another in order to get the system initially set up, it is recommended that the procedures outlined on Factsback Document #520 (ftp://ftp.goldminesw.com/public/faxback/tech/520.zip) are followed.
Duplicate data
Duplicate data can only occur if the RECIDs of the records are different for two records that should be the same. This most commonly occurs when two records are entered for the same contact from two different systems. In this case, the records may contain the same data, but are treated as two separate records, thus they are not synchronized and appear to duplicate.
Duplicate records can also be caused if two GoldMine 3.2 systems were converted to 4.0 and the data in the fields of the record was not the same. For example, the lookup records in 3.2 did not synchronize so there were no unique identifiers for lookup records. During the conversion, GoldMine 4.0 uses the data in all of the fields to generate a RECID for the lookup record.
The problem can occur if there are two lookup records that are intended to be the same, however they are slightly different. Even if both lookups were for KEY1 and the first lookup had the value "EU" and the second lookup had the value "EU //End User" which would put the same value "EU" in the KEY1 field when selected, they would generate different RECIDs when converted. This problem can occur with records from any file that did not synchronize in 3.2.
BDE Errors
If you encounter a BDE error during the synchronization process, there are several steps to correct the problem.
There are two types of BDE errors that you may encounter: non-recoverable errors and recoverable errors. An example of a recoverable error would be a corrupt BLOB field. GoldSync can continue building the transfer set even after encountering this error. This still indicates a problem with the GoldMine database that does needs to be addressed, but it does not nullify the synchronization process. A non-recoverable error would be one involving errors writing to the output file or while accessing the synchronization files (sync site, sync task, etc…) If you are encountering a non-recoverable error, then you must resolve this issue before you will be able to complete synchronization. Recoverable errors should still be addressed, however, the synchronization process will complete.
Most BDE errors encountered during synchronization are due to problems with data. The way to resolve these problems is to repair the data in question. See FactsBack Document # 506 on Solving GoldMine 4.0 Database Errors for more information on correcting these problems.
TAPI errors
Most of the errors that you encounter when using a modem will be TAPI errors. TAPI errors are shown in the Process Monitor logs but they are not GoldMine errors. They are actually generated by the operating system. Some common TAPI errors and resolutions are:
More information on troubleshooting modem problems can be found on Document #651,
Diagnosing Modem Communications Issues.
Winsock Errors
Like TAPI errors, Winsock errors are generated by Windows. Winsock errors indicate problems encountered by the Operating System connecting to a TCP/IP host. You will only encounter Winsock errors when attempting an Internet sync. Extended information on Winsock errors can be obtained from: http://www.sockets.com/err_lst1.htm
Other Resources
SyncSpy - (ftp://ftp.goldminesw.com/public/utility/syncspy.exe) - this utility can be used to view the TLOG entries of information stored in GoldMine.
BR4 - (http://www.redstonesoftbase.com) - This freeware utility can be used to manually browse GoldMine's database files.
Copyright (c) 2002 FrontRange Solutions Inc.
All rights reserved. You may use this document for personal and informational (non-commercial) purposes, provided that the copyright notice and all other notices and permissions appear in all copies, the document is not copied or posted on any network computer or broadcast in any media and modifications are not made to the document. Use for any other purpose is expressly prohibited by law, and may result in civil or criminal penalties.
The information contained in this document is provided “as is” without warranty of any kind. To the maximum extent permitted by applicable law, FrontRange Solutions disclaims all warranties, either express or implied, including warranties for quality, accuracy, merchantability, fitness for a particular purpose, title and non-infringement; and in no event shall FrontRange Solutions or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of profits or data or special damages, even if FrontRange Solutions or its suppliers have been advised of the possibility of such damages.