|
We have two servers using replication between our Alberta and Virginia offices. It's all been working fine for quite a while, but we needed to get a new server for the VA office. So we set that up with the same folder shares (it's Win 7 Pro). We downed ADS on the old server, copied all the files over and started ADS on the new server. When we change information in those files, it replicates to our Alberta server, but when we make changes on the Alberta side, it doesn't replicate to the new VA server. When we view the connections in the data architect there, we can see the Alberta server trying to connect, but the error log fills up with a bunch of 7003 errors. I looked that up and it says 'maximum number of users exceeded', but we are only at 1 connected user out of 10 that our license is good for. Does anyone have any ideas what would cause that? |
|
I managed to get it working. One of two things that were done at the same time since the last test will have been the culprit. Either User Account Control, which is now turned off, or the fact that the computer was using both wired and wireless network connection at the same time. UAC was turned off, computer rebooted, then the wireless was disabled, and now the replication is working both directions. Sorry to waste your time, but maybe this will help someone else down the road... 1
My co-worker just came over and talked to me about this issue when you posted this. I think he may have figured it out. He was thinking that perhaps a firewall rule is not allowing the response packets from the server back out. Since it clearly received some packets inbound (thus the 7003), it seems the firewall was updated to allow inbound on 6263. But maybe it was blocking them outbound. Disabling UAC might have "fixed" this. But maybe you can check the firewall for such a rule and then re-enable UAC (which is probably a good idea).
(09 Oct '13, 16:00)
Mark Wilkins
We actually had the windows firewall turned off while we were trying to get this all working since we are behind a router anyway, but it still makes sense that turning off UAC might have been the winner, thanks.
(09 Oct '13, 16:09)
Steve
|
|
I would verify the connection path in the subscription definition at the Alberta server. If there is a new IP address, then it could be that an update is needed at the Alberta server. The obvious example related to that is if the connection contained the IP address. But also if the IP address were provided in an ads.ini file, then it would need to be updated. However, that does not explain a 7003 error. A bad connection path should result in a 6000 class error typically. So that just leaves me with some questions: 7003 errors being logged at the VA server or only at the Alberta server? * Does the "Users Rejected" count increase at the VA server? For example, you can look at it with the configuration utility (ads_cfg.exe). The right column in the grid shows how many users have been rejected. If it is generating a 7003 error, then that should increment by one every time it happens. (Also, maybe verify at the same time that the "Configured" column does indeed show 10). * What version of ADS is being used? * Can you connect to the VA server from the Alberta site with something like Advantage Data Architect? Edit: Based on the answers to the first questions, a couple more come up.
The connection path is the same, the folders on the new server have been setup and shared in the same way. The IP address is also the same, just forwarded to the new server via the router. The 7003 errors are being logged only on the VA server. The configuration util on the VA server doesn't show rejected users, but it does show many rejected connections, and definitely shows 10 for configured users. Version is 10.10.0.28 on both servers. Haven`t tried just connecting manually from arc, but probably will give that a shot in a while.
(09 Oct '13, 13:47)
Steve
Yes, we are using the internet port. I`m not sure how to tell if it is TCP/IP or UDP. In the Advanced tab of the subscription the Target Connection Type is Advantage Internet Server, but the Communication Type dropdown is blank (does that just equal "Default", and if so which type is that?) If that partially connected count was messed up is there a way to reset it and would it not get reset when ADS was restarted?
(09 Oct '13, 14:55)
Steve
Restarting ADS would definitely reset the partial connected count. If I recall correctly, the default is UDP, getting UDP working across the Internet would normally be difficult I think. So in reality I would suspect it is TCP. The ads.ini file at the "client" which would be the Alberta server in this case can specify USE_TCP_IP=1 to force TCP.
(09 Oct '13, 15:27)
Mark Wilkins
|
Can you "copy" a few of the 7003 error entries into the question? In particular I would like to see the file and line numbers associated with them. That can help narrow things down (sometimes).