Link to home
Start Free TrialLog in
Avatar of TTCLIVE
TTCLIVE

asked on

Synchronization Times Out

I have a remote databse user trying to synchronize across a VPN connection. Whenever this one user tries to synch, he gets this error:

"Synchronization timed out. Please contact your administrator for assistance."

and these are the logs on the main database synch logs:

[ Info | 3/6/2008 8:59:13 AM ]Message: Synchronization started.
[ Info | 3/6/2008 8:59:13 AM ]Message: Server object created.
[ Info | 3/6/2008 8:59:15 AM ]Message: Checking if schema changes are available for sync.

What is weird is that they were synching just fine for about a week, the it just stopped working. I cannot think of that the problem is, and I HAVE TRIED DOING ALL OF THE DATABASE REBUILDS FROM ACTDIAG to no avail.

If I recreate the database, it synchs fine, then stops after a week or two again. I am stuck on this, any help would be great!! Oh Yeah... I have another user at the same location synching to a seperate database internally without any issues, so it looks like it's just on the one database or at the remote database in question.
Avatar of Mike Lazarus
Mike Lazarus
Flag of Australia image

Are you synchronising attached files?
Have you upgraded to 10.01?
Did you do the schema and sync rebuilds in ACTDIAG?

How big is the database?
If syncing attachments, how many and total size?
Avatar of TTCLIVE
TTCLIVE

ASKER

>>Are you synchronising attached files?
No.

>>Have you upgraded to 10.01?
ACT! by Sage Premium 2008 (10.0) (ST Edition) Version 10.0.0.237, Hotfix 1 (on both ends)
Sorry I was hinking it was EX Edition for some reason, it's actually ST Edition.

>>Did you do the schema and sync rebuilds in ACTDIAG?
Yes.

>>How big is the database?
Remote DB: 66,623 KB
Local DB: 1,662,080 KB
Can you try the update to 10.01

Server first, the workstations - always backup first

Also, how complex is the sync set rules... simplifying these can help also
Avatar of TTCLIVE

ASKER

>>Can you try the update to 10.01
I suppose I can, but it would mean upgrading on the 40 pc's and the 4 servers running the software. I would prefer not to do this without much planning and a weekend to troubleshoot any issues that might arise. Just to check the upgrade package though, I went to "Help" "ACT Update" and it tells me I am using the most recent version already.

Is there somewhere else I need to go to get the 10.01 version? And if so, does it require a complete unintall and reinstall of ACT?

>>Also, how complex is the sync set rules... simplifying these can help also
Synch set just says to only synch that one user's contacts, nothing to drastic.
They didn't put 10.01 in the auto update because in a sync environment you must do all systems and they didn't want one user doing it and screwing up the IT person's day :-)

You can find 10.01 here - http://www.act.com/support/updates/index.cfm

It shouldn't need an uninstall first

Also:

ACT! has some timeout values, one of which is "DatabaseCommandTimeOut.Long" = 3600 seconds.  You can actually change this setting, but it isn't always beneficial if the problem is deeper.
 
2 cases I can think of:
1. Many, many changes have been made to either this specific Remote (import possibly, or a very large file was attached), or many changes made to the server and the rest of the sync machines making the sync especially long.
2. There could be a corrupted file attached to the DB messing up your synch.

If it's #1, sometimes you can sync multiple times, even though it times out, the sync does get further along and might finish the next time. But that's a might. If you bring the machine in to your home and use an ethernet cable to connect the machine you can transfer a lot more data than over a VPN.

If it's #2, it's a little more hairy. If there's very little new data on this remote, recreating might be the simplest.

Could it simply be this user has a bad internet connection? I have a customer who lives on a ranch in the country. In his case, the remote synch software can be amazing, but if he can't transfer info, not much can be done.
Avatar of TTCLIVE

ASKER

>>ACT! has some timeout values, one of which is "DatabaseCommandTimeOut.Long" = 3600 seconds.  >>You can actually change this setting, but it isn't always beneficial if the problem is deeper.

I dd change the timeout values to no avail.

>>2 cases I can think of:
>>1. Many, many changes have been made to either this specific Remote (import possibly, or a very >>large file was attached), or many changes made to the server and the rest of the sync machines >>making the sync especially long.
>>2. There could be a corrupted file attached to the DB messing up your synch.

I think you hit the nail on the head. We have many users in this database and there are about 15000 changes per day in the database. So If the database is trying to synch all those changes and not just the changes to the remote database leads, that might cause the problem.

Does the synch try to update all the changes made to the main database, or just the contacts in the remote db?

>>Could it simply be this user has a bad internet connection? I have a customer who lives on a ranch in >>the country. In his case, the remote synch software can be amazing, but if he can't transfer info, not >>much can be done.

No they have a 10Mb/s bown and 1Mb/s up consistantly. I also have the vpn connection (point-to-point) QoS'd so that they get priority, but it doesn't seem to help.
So they're in remote offices... you wouldn't get 10Mb over the 'net

It should just work with the contacts in the sync set. Does this user have a larger set than others?
Avatar of TTCLIVE

ASKER

>>So they're in remote offices... you wouldn't get 10Mb over the 'net
Right, that's just their internet connection speed, so you know it's not a connection speed issue.

>>Does this user have a larger set than others?
He has about 4500 contacts. Compared to the 10000 contacts that are being synched at another location succesfully (to another database), it doesn't seem like that should be such a big deal.
What speed do you have in the office?
Avatar of TTCLIVE

ASKER

Just a T1 (1.5 Mb/s) but like I said, I am synching another database externally with 10000 contacts and it does not time out, it just takes a while.
Ok... so they can't get 10Mb... and the 1.5 is split with all the users and any other 'net activity.

But if it does time out, it should be able to continue if you try again later.

After it times out, can the user try after hrs when no-one else is doing much?

When you did the ACTDIAG repairs (I hope including sync objects and schema rebuild), did you do the remote AND the publisher? Maybe it's one bad record and if somethins is done with that record it fails. The other user might not be getting the problem record (or records) - just a thought.
Avatar of TTCLIVE

ASKER

I see what you are saying. Yes, the remote user is trying to synch after hours when nobody is here (via synch schedule) and it's not working.

So what you are saying is maybe just try over and over again until it finally synchronizes all the data that has changes since the last synch?

So I could set the synch schedule to try again every hour and maybe sometime in the next 24 hours it might actually work?
It would show if it's a data issue or a VPN/connection issue

Try to do it when no-one else is syncing as one user with the number of changes you're talking about might take all the bandwidth and the other falls over
Avatar of TTCLIVE

ASKER

>It would show if it's a data issue or a VPN/connection issue
What do you mean, what is "it" and where does "it" show that?

>>Try to do it when no-one else is syncing as one user with the number of changes you're talking about might take all the bandwidth and the other falls over.
Are we talking about the same thing...I've already said it's not a bandwidth issue, I am synching a larger database without any issues, I don't see how this smaller synch could be running out of bandwidth. And I already told you "Yes, the remote user is trying to synch after hours when nobody is here (via synch schedule) and it's not working."

It seems to always be timing out on this message:
"Message: Checking if schema changes are available for sync. "

What exactly is happening at this point in the synch process, and what is supposed to happen nex that is not happening. I think if I knoew that I might be able to figure out where the issue is.
"it" - the timeout issue you're having
"show" - if it works when you try when nothing it on the connection, it's a simple bandwidth issue

If the big one is syncing when the smaller one starts, it might possibly cause this

Schema changes - this is why I asked about what you did with ACTDIAG above. See http://tinyurl.com/2gxylf

It's trying to get and database design changes (users, fields, etc).

Are the remotes allowed to do Remote Admin?
Avatar of TTCLIVE

ASKER

I don't get that schema error.
Only one database in synchronizing at a time.

>>Are the remotes allowed to do Remote Admin?
No, the remote users are set up as "Standard" users in the database. No admin rights.
Avatar of TTCLIVE

ASKER

So what you are saying is maybe just try over and over again until it finally synchronizes all the data that has changes since the last synch?

So I could set the synch schedule to try again every hour and maybe sometime in the next 24 hours it might actually work?
Re the schema error... the KB is for ACT! 8... might have changed the error with 10
Please use ACTDIAG and do the rebuild schem and sync objects on the Publisher and Remote

Only one db not an issue as they are doing different areas of the db

Always good to either allow remote admin or at least add and admin user to the remotes. Other wise you can do maintenance on the remotes or even roll out schems changes

Yes, try it for a while... see if it connects again. If so, it's just a bandwidth/connection issue
Avatar of TTCLIVE

ASKER

>>Please use ACTDIAG and do the rebuild schem and sync objects on the Publisher and Remote
I already have.

>>Only one db not an issue as they are doing different areas of the db
You lost me, what are you talking about?

>>Always good to either allow remote admin or at least add and admin user to the remotes. Other wise >>you can do maintenance on the remotes or even roll out schems changes
The remote users are "Standard" but the administrator user is also on the remote emd so as to facilitate administration.

>>Yes, try it for a while... see if it connects again. If so, it's just a bandwidth/connection issue
Cool I will do that and post back with results in a day or two.
ACTDIAG - so you've tried the fixes in http://tinyurl.com/2gxylf on BOTH copies

If it's not a connection issue... ie still failing in a week, we should look at the update to 10.01
Backup all copies first, then do server, LAN Workstations and remotes
Avatar of TTCLIVE

ASKER

Yeah, I tried those fixes on both copies of the database.

The thing that gets me is that it's not telling me that it's changing anything, it's just stopping at that point of the synch and timing out. Is it making changed before that point of the synch, am I just wasting time trying to synch more often?
It's trying to get the schema to check for any changes... it's a big chunk that it has to do first.

I'd make it every 3 or 4 hours for a few days and see if it gets it going.

Usually a timeout that happens once or twice isn't a major issue as it will keep going when it next tries.

how long did you increase the timeout to?
You might also post the sync log from the remote after a fail
Avatar of TTCLIVE

ASKER

I changed the timeout to 60 seconds. I will post the log here when I get it from the remote site.
You might also increase the ConnectionTimeout (it's a pull down) to 2 minutes... or even longer
Avatar of TTCLIVE

ASKER

I had him try to troubleshoot today, so these are timestamped today, all the logs are the same though:

That's it, no other errors or anything.
Avatar of TTCLIVE

ASKER

======== SYNC SESSION - 3/6/2008 10:15:27 AM ========
[ Info | 3/6/2008 10:15:28 AM ]Message: Sync remote client created.
[ Info | 3/6/2008 10:15:40 AM ]Message: Checking if schema changes are available for sync.

======== SYNC SESSION - 3/6/2008 10:12:26 AM ========
[ Info | 3/6/2008 10:12:26 AM ]Message: Sync remote client created.
[ Info | 3/6/2008 10:12:28 AM ]Message: Checking if schema changes are available for sync.

BTW: You haven't done any sync set changes for other users?

Another idea:
Can try detaching the database on the remote machine and reattaching it. This forces some changes and may get you around this error.
To detach the database, open up the ACTDiag
Select the database, right click on it and select 'Detach Database'
Once that is done, exit the Diag tool, delete the .pad file for the database, launch ACT and open the database using the .adf file - File | Open - Change File Type to ADF
It will do some checking and rebuild the PAD
Once that is done, attempt to sync.
Avatar of TTCLIVE

ASKER

>>BTW: You haven't done any sync set changes for other users?
I have made changes to the synch sets for other users, how does this affect this particular user?

I will do all the rebuilds after hours today (again) and then try to synch.
Then I will have him detach and reattach and try to synch again.
Then I will have in synch every so often for the next couple days and see where we are at.
There is a known issue, in some rare cases, where doing a lot of sync set changes can cause sync to fail. I know Sage are working on it, But I would think that would cause all the remotes to fail, not just one.

Hopefully the detach, delete PAD and open ADF will fix it.
If not, I guess you'll end up bring the data in, merging in the main database and re-cutting...

Which ever option, try to recall if there were significant sync-set changes before it fails (if it ever does again)

You might also consider giving them Remote Admin tasks - just to allow the user to Check/Repair, Back and roll in any Schema changes from the server
TTCLIVE,

I'm not going to give you 20 posts on this but to cut to the chase you're running into an unresovable issue.  You're best hope is they fix your problem in a future release but in the meantime the most economical solution is to recut the remote database.

By the way, one thing that did fix this problem is a standard compress (under Tools, Maintenance) as opposed to through ACTDIAG.

Don't shoot the messenger.

Steve
Avatar of TTCLIVE

ASKER

Well, no luck on doing the database repairs and detaching and reattaching the database. It's still not synching.

I did encounter an error the first time I detached the database and tried to open it again. The error was something like : "A transport-level error has occured. There is no database at the other end of the connection."

I didn't get the exact error, but I got that much. Detached and reopened the database again and it went through the check and loaded just fine. Then I did a rebuild on both ends again and tried to synch again to no avail!!!

I tried to export the data so I can import it to the original database, but it will not export the "Notes" so I don't know how to get the data out of that tatabase without losing it.
Avatar of TTCLIVE

ASKER

I am going to let it try to synch for a day or two and see what turns up.
ASKER CERTIFIED SOLUTION
Avatar of Mike Lazarus
Mike Lazarus
Flag of Australia image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of TTCLIVE

ASKER

Well, I have had it trying to synch every hour for the last 5 days and it still will not synch up, on to plan B!!

I will have them make backups at the end of the day and follow your instructions to get their data into the database. I'll let you know the results.
Avatar of TTCLIVE

ASKER

Well, I eventually did get the data into the database and pushed back out to a remote database for the user. Then everything was working fine, and it stopped synchronizing again. Luckily, I was tracking changed to the database that might cause that problem and here's what happened:

** I imported another 15000 contacts and changed the access on them to limited access. **

That's it, that's what broke it. So I guess I am going to have to make a new remote database any time I'm going to make major changes weather or not it effects the remote user!!

I'm wondering about the web based ACT, how does that work over a vpn connection? Is it slow, does it take a lot of bandwidth? Just trying to think of alternatives to doing it this way.
TTCLIVE,

A lot of changes = a lot of info to synchronize.  My clients are happy with ACT! for Web.  Keep in mind you can't import, perform adminstrative changes (db structure, design layouts, etc), and a few other misc options.  Try it at:  www.act.com/webdemo.  The user name is:  Chris Huffman.  There is no password.

I think it does a really good job of emulating the traditional client...and of course, no synching  ; )


Steve
Are these all new contacts that you're syncing or are some duplicates and merges?
Avatar of TTCLIVE

ASKER

SStroz:
"A lot of changes = a lot of info to synchronize"
But those changes do not affect the remote user, he shouldn't have to synchronize anything that doesn't fall into his sync set right?

"Keep in mind you can't import, perform administrative changes (db structure, design layouts, etc), and a few other misc options."
Is that after the initial setup? I mean can I create all my custom fields and layouts to use as default and then just not change them after that, or do I not have the option to use custom fields and layouts at all?

GLComputing:
Some were duplicates, but I had it check for duplicates on import and it caught most of them, then I just had to go in and delete the ones it missed. I don't do any merges, just keep one contact and delete the other.
Re "lot of changes" - check the Edit Dates to see how many of the user's records have been update. Or use Lookup | Contact Activity

Re admin tasks on web - you can still do all of these on the server or from a full client on the AN

Re dupes - are you sure you delete the new ones and not the old ones?
Avatar of TTCLIVE

ASKER

Only 113 records belonging to that user were changed on the day that I imported all those contacts.

Admin tasks...cool, I think maybe I will try it out for a while and see how it goes with a couple of web based clients. Is there a trial version I can try that won't effect the installed ACT program already on the PC?

Dupes: Yes, I tag all my contacts with an import date so I know when I put them in and only delete the ones that are dupes from the same import list (that are not being used yet).
The trial version of the Web is not available for download, but you should be able to get it from an ACC or Sage.

While you need to install a different server application, you could do this on another machine and still have it use the database from the machine you're already using (providing it's Premium 2008). Or you could replace the version you have on the server as it knows the difference between web and full client license keys.

BTW: Do you ever do changes to the syncsets going to the users?
Avatar of TTCLIVE

ASKER

Cool, I will call our ACT rep and see if they can hook me up.

I do not make changes to the synch set for the user once their database has been created. I ocassionally have the need to create a new remote database and synch set, but I did not in this instance.
Avatar of TTCLIVE

ASKER

Sorry, the post got off track, so I wanted to make sure you got your points for the original problem and thank you for all your extra input and advice. If I need to I will open another post for further discussion on the web product.

If you think of anything that we did not try that might fix this issue, please post here, I will keep an eye out and am always willing to try new ideas that might fix the issue.
Just wondering... how many sync users?
How many LAN users?
Avatar of TTCLIVE

ASKER

3 synch users, 35 or so LAN users in 2 different databases.
How complex is the query for the sync sets?

One or two fields or a big query?
Avatar of TTCLIVE

ASKER

Single field: "Record Manager = User"

Synch set includes both the remote user and the Administrator (so I can adminster on their local PC if I need to).
Ok... I heard of a similar issue with complex syncsets, but obviously not the case for you.