12-17-2010 08:01 AM
ACT! 2009 184.108.40.2067
7 remote users
Syncing via VPN
5500 contact database
We are encountering problems with remote databases having differing numbers of contacts to each other and the publishing database. Some remotes match the publisher, others are up to a few hundred contacts different. The remote users also have exceptions reported from synchronisations varying from a few at best to nearly 1500 at worst.
We have used check and repair within ACT! and we have used all of the maintenance tools in Actdiag on both the publishing database and remote databases.
We froze activity on the publishing database and merged one of the remote databases with the publishing database. We then recreated that rdb and upon unpacking this it immediately had two contacts less than the publishing database. A sync did not correct this and threw-up 315 exceptions.
We then tried a sync to another remote database. This started attempting to update 73500 records at a rate of about 15/minute. So we abandoned that, restored a backup of the publishing database and recreated the effected remotes and are back at square one.
Any explanation of these behaviours and suggestions for resolution would be much appreciated.
12-17-2010 09:37 AM
01-04-2011 02:48 AM
I may have an explanation for the new remote database having two less contacts than the merged publishing database as originally reported.
The sync exceptions immediately after the merge and remote database recreation are still a concern and unexplained.
However, regards the two missing contacts, there were two instances of duplicate contacts in the publishing database. Would one of each duplicate contact be lost when the remote is created?
Synchronising other remotes following merging of a remote with the publisher seems impractical as too many records are then deemed changed.
I'm thinking that the way to go to correct the issues is going to be to backup all remotes, merge one at a time with the publisher, correct any resulting issues (duplicates etc) and then recreate each remote database. Does anyone have any strong opinions or advise on this approach?
Can anyone explain why sync exceptions would be reported on a freshly recreated remote database?
01-04-2011 06:29 AM
It is hard to determine what could be causing the difference in number of contacts, but the first things to look at are:
- is the sync set for the remote(s) set to all contacts or is there is a sync set defined?
- are the missing contacts set to Private for a different user?
There are settings that can be changed to increase the error logging. Since you have posted this in the Sage ACT! board, I assume you are using 'Application sync' - meaning that the main database is open on the host machine when the syncs are performed. Here is the information for changing the settings:
Config file name: ActSage.exe.config
Location: C:\program files\Act\Act for Windows
To change the config file:
Open the config file with 'Notepad' and locate these lines -
Change the value from 0 or 1 to 4. This will provide the most detailed error reporting.
To view the log file itself after closing Act! -
file name: synclog.xml
location: c:\documents and settings\all users\application data\act\act for windows#
Note: be sure to make a copy of the Config file before making changes to it. Then after testing your syncs you can simply rename the files to put it back to original state. It is not recommended to leave the logging set to a higher value for long periods due to the amount of data it can produce.
01-04-2011 08:43 AM
Thanks for your response Greg.
To immediately confirm some details:
- all sync sets are configured for all contacts.
- as far as we are currently aware all contacts are set to public. I will double check this. Any private contacts could explain differing numbers of contacts but I don't see that this would give rise to sync exceptions. Is this right?
- we are using application sync.
Thanks for the info on increasing the logging detail. I will make the changes and come back with whatever this reveals in due course.
01-05-2011 07:21 AM
There's certainly plenty logged now. None of it appears particularly useful or even very readable though.
I've now got a log resulting from a sync on a database that gives 2 exceptions, another that gives 4 and a third that gives nearly 800 and I can't find anything that helps. I've done a key word search on "exception", "error" and "fail" and these words don't occur in the log. Should I be looking for anything specific?
I'm rapidly loosing confidence in ACT!. Stating that in the past tense would probably be more accurate. The problems originally described have developed without any notification being flagged. Checks and balances within ACT! seem non-existant. Only by users anecdotally comparing numbers of contacts and subsequently actively reading the sync log have the problems become apparent at all. The numbers of sync exceptions continues to rise on a daily basis. None of the maintenance tools within ACT! nor ACTdiag have been of any use. Freshly created remote databases exhibit the problems originally described. Information is so lacking that I'm not even clear on what a sync exception is or what the impact of them might be.
Any help at this stage would be much appreciated.
01-07-2011 03:45 AM
Well I seem to have a solution even if no explanation.
In testing I have successfully merged a remote database with the publisher, removed sync sets and remote databases (I have left users intact or otherwise record ownership is lost), created a new sync set, created a new remote database and this syncs without any exceptions.
Two contacts are still lost in the remote database but this has happened with the same two contacts in 3 out of 4 instances. These two contacts are not the duplicate ones that I mentioned previously so I can't explain this and to complicate understanding this issue in one instance where I recreated a remote database these two contacts remained intact. The two missing contacts export into the remote databse without problem and sync exceptions do not result after this.
All I can do now is go through this process for all remote databses on the live system, ensure that syncs are performed regularly and hope that this mess does not develop again.