This was an interesting piece of a larger application. Breaking Par worked on an application where developers would have a database on a development server and want the database published to a production server. Originally, the developer would fill out a form saying where the database was in the development environment - the development server name and the path to the file.

You would think that the server and file name would be easy to enter, but it wasn't for whatever reason. There were many times that the developer would put in the wrong server name and/or wrong file name. Most of the time is was a typing mistake, but this would make the automatic deployment process fail because the server and/or file could not be found. A new solution had to be considered.

Breaking Par decided to put their API knowledge to good use. Instead of having the developer enter in a server name and file name into two plain text fields, the developer would enter in a link in a rich text field. The link could be any link - database, view, or document - as long as it came from their source application.

An API program was written to read the rich text field and search for the first link in that field, ignoring any text that might be present. Once the link was found, the information that is stored with the link was read. This information includes the replica ID of the source database. Then every server in the development domain was searched until that replica ID was found. Once found, the server and file name were put back into plain text fields on the document, and the rest of the automatic deployment process could continue.

When the process first started, a list of the server names in the domain were made. If a server in the domain was down, that server was skipped for the time being. If the source database couldn't be found, but there were servers that were down, then the process would start up again in a half hour and try the servers it hadn't searched yet. Only after all servers were searched (without the database being found) would a failure message be sent back to the developer.

There were only two drawbacks with this method. The first was that one server name needed to be hard-coded. This one server name was the "source" for the domain. That server's address book was searched to find the names of other servers in the domain. That meant that other development servers could be added to the domain without having to adjust the API program, but the name of the main development server couldn't be changed. It also meant that if that main development server was down, none of the other development servers could be searched (since their names wouldn't be known). The customer was comfortable with this drawback, however.

The other drawback came in to play if the developer had multiple replicas of their database in the development domain. This is something that very rarely happened, but the potential was there. The first instance of the database found would be used, whether or not the developer had been synchronizing the multiple replicas. Again, the customer was comfortable with the risk of this happening.