Categories

Follow our news:

Follow canonburysvcs on Twitter Follow Canonbury Services on Facebook Follow Canonbury Services' news by RSS Follow Canonbury Services' news by Atom Follow Canonbury Services' news by email

NEWS & TECH BLOG

Debugging GoldSync connection problems

19/02/2015 – in GoldMine, Techniques

When facing connection problems it’s always best to start with a checklist of things that GoldSync needs in order to be happy. Some of these steps are blindingly obvious, but you’d be surprised how easy it is to miss out something simple!

Check that:

1. GoldMine is installed on the designated GoldSync server and the GoldSync process is started in silent mode. It can be started as a service instead, but this isn’t recommended as it’s then impossible to see what it’s up to. For debug purposes GoldSync can also be run from within a full GoldMine session; this gives you easy access to the process properties etc should you need them.

2. The GS status window says “Listening for Incoming Connections”. If not, check the Active Period page in the process properties in the GS Administration Centre in GoldMine. Is everything ticked?

2. The server is accessible (either by IP address or server name) to the remote machine. If the remote is outside of the local network then provision must be made to publish it to the outside world.

3. Any firewalls between the server and the remote have the GS port opened (5993 by default).

4. GS is actually listening. From DOS on the server type: netstat -an | find “:5993” and look for a response that includes: TCP 0.0.0.0:5993 0.0.0.0:0 LISTENING.

5. You can connect to GS. You can check this by typing telnet xxx.xxx.xxx.xxx 5993 from a DOS window (substituting your server address for the xxx). If it opens a communications window then you have successfully reached GS. If this works on the server itself but not on the remote then it points to a firewall problem or other blockage.

6. The remote is configured to connect using the correct IP address (or server name) and port.

If going through the checklist fails to cure the problem then you next need to establish whether:

a) despite all of the above, the remote is still failing to connect;
b) it is connecting but is being refused;
c) errors are occurring during the sync.

Do this by watching the GS status window on the server and the process monitor on the remote. What do you see at either end? Are there any error messages?

Share