We have performed quite a number of ArcFM™ Replication installations for utilities implementing ArcFM Viewer™ for ArcGIS Engine. So I was a bit surprised this week when I ran into a new ArcFM™ Replication bug while onsite at Douglas County out in WA. After triple checking all of my settings, searching the internet for anyone else with the issue, and pulling out a few hairs I gave up and called in a ticket to our good replication friend, Matt Denton, with Telvent support.

This is always a last resort for me… call it pride or stupidity but I like to try and figure out the issue myself if at all possible. But in the end it was a true bug and I would not have figured it out on my own. So once I got the workaround in place I wanted to get it posted onto the internet to hopefully save someone else a few hairs (I checked with Matt and he thought it was a good idea too)!

The issue occurred in a fairly standard implementation for a file geodatabase replica that was replicating against a SQL Server 2008 SDE enterprise geodatabase. In the below image the error was occurring right at the top of Process A where the replication server attempts to retrieve updates from the SDE GDB:

If you have every configured replication you know that the ArcFM™ Geodatabase Replication Administrator tool validates all of your configuration values when you attempt to save the configuration file. For example in the below picture if I try to save the config file with invalid SDE connection information, the tool warns me and forces me to fix the issue before I can actually save the file:

But in my case this week, I knew for SURE I had all the correct valid information for my SDE connection and the tool was also validating it with no errors. I had checked it in ArcCatalog repeatedly and saved several different config values to ensure I had all of the settings absolutely correct. However, when I ran the server replication process it failed immediately every time with a simple error of “Bad Login User“. This error was logged in the event log but did not provide any other intel other than that it was failing when trying to open a connection to the database.

Long story short, once I got on the phone with Matt I learned that if there is an upper case letter in your SQL server password then this will cause exactly this issue. The problem is in the encryption code that is encrypting your password into the plain text xml configuration file. Apparently the password is converted to all lower case before being stored and then when it is unencrypted during the execution of the server process it is no longer the correct password. This one was pretty misleading because it passed the validation against the SDE database which must be occurring before the encryption occurs.

The two options to get around this issue are as follows:

1. Change your SDE password to all lower case. Apparently most clients use lower case passwords for SDE and the fact that I am just now hitting this error proves that I do too! Easy enough unless your security policies dictate using an upper case letter and/or the SDE password is already configured into a bunch of other applications… so….
2. Manually change the SDE password to a plain text (non-encrypted) value after saving the config file. This is the option I used this week. After saving the config file (passes validation, encrypts the password in all lower case, and saves the config file) you can open the file in notepad, textpad, etc and replace the encrypted password with the non-encrypted value including the upper case letters. This makes editing the configuration a bit more painful going forward but hey… it works. And most techy folks don’t mind editing XML files directly anyhow. It comes with the territory.

To be clear, this bug exists in Telvent ArcFM™ Replication version 10.0.3. Matt indicated that it was being fixed in version 10.1 but might not be in 10.0.3 SP1. I am also unsure when the bug was introduced and/or if it’s always been there. If this post saves someone else some time it will have been well worth the time to post it and get it into the Google searches! Happy replicating!