Manage Learn to apply best practices and optimize your operations.

A Lotus Notes Domino database replication primer for administrators

Discover some helpful tips about database replication for administrators new to Lotus Notes and Domino.

For anyone learning about Lotus Notes and Domino, one of the most important concepts is database replication. This article will serve as a primer about replication, although at the end of it are some technical details for advanced users.

Replication is the process of synchronizing more than one copy of a Notes database. The two (or more) copies might be on different servers, or they might be on a personal computer and a server. Synchronization means that each copy of the database gets the same data. Having the same data in multiple locations is important because a Notes database makes assertions about the world. What time is the Project Treadstone meeting? What are the contents of the e-mail that Tom sent to Katie on August 1 at 10:00 AM? If Notes databases are not synchronized, then some of them contain false assertions.

Notes pioneers invented replication to allow Notes to take advantage of two technological developments: client/server and remote computing.


Chuck Connell
PresidentCHC-3 Consulting

Why do replication at all? Couldn't you simply keep all the data for each application in one place on one server? Well, the reason early Notes pioneers invented replication was to allow Notes to take advantage of two technological developments that were going on at the time: client/server and remote computing.

Previously all computing had been either server-based (mainframe or minicomputer) or strictly PC-based; now the client/server model was growing in significance. In addition, there were these newfangled machines called laptops that were growing in popularity. People were realizing they could use laptops for their office work. . .when they were not in the office. Replication tied in with both of these technologies, and it was very hard (if not impossible) for other software systems to work on these new computers.

While the idea of replication is simple, implementing it in a practical manner can be complicated. Here are some of the problems that arise:

Suppose two people edit the same document at (or near) the same time, on two different servers. During replication, which document should be considered the latest version? Although this situation occurs less often than you might expect, when it does occur, it is called a replication conflict and is flagged with a black diamond in the Notes view. Human intervention is required to resolve the conflict.

Suppose two people edit the same document at the same time on two servers, but they edit different fields. Is this still a conflict? On earlier versions of Notes it was, but now Domino contains an option to resolve this conflict by merging the latest copy of each field into one document. (See Domino Designer/form-name/Design/Form Properties/Conflict Handling.)

When two servers replicate a given database, which documents should be exchanged? Every document, no matter when it was created? Or just recent documents? Should every field be compared in the replicating documents, or just certain fields? How should Domino handle deleted documents, when a document exists on one server but not on the other? (The answer is that Domino contains options to control what happens in each of these situations. See File/Database/Properties/Replication Settings.)

What about design elements? If two people modify the same form on different servers, should this problem be flagged with a black diamond in the form list? (Answer: It is not. Replication conflicts are not flagged for design documents. The latest version wins.)

For Domino servers, you set up and control replication with server connection documents, which are found at names.nsf/Configuration/Servers/Connections. For Notes workstations, you control local-to-server replication from the Replication workspace, which you enter by clicking the purple folder icon on the far left of the screen.

Replication is sometimes referred to as the "occasionally connected" distributed database model. When Notes first appeared, many experienced database administrators were shocked by this model. While working at Lotus in the early 1990s, I had many conversations with industry veterans who resisted this idea. Typically, their reaction was: "But the databases are not synchronized!"

Keeping all copies of a database synchronized (the same data everywhere at all times) was a bedrock concept of distributed data sets, and Notes was breaking this dictum. At Lotus, our answer was that the occasionally connected model allowed Notes to do things that traditional database systems simply could not do. We also pointed out that there were certain applications for which Notes replication was not appropriate, such as real-time banking records and airline reservations systems).

How does replication work at the nuts-and-bolts level? The replication software makes use of a set of identifiers on databases, and identifiers and version counters on documents (notes). Here is a detailed explanation of these identifiers and their roles in the replication process. The documentation is from the Notes/Domino C API programming kit, and was written primarily by Martin Cox in 1992 when he worked at Lotus.

For further information see Lotus Domino Administrator 6.5.1 Help/Index/Replication/Described.

Chuck Connell is president of CHC-3 Consulting, a consulting company in Woburn, Mass., which helps organizations with all aspects of Domino and Notes.

This was last published in August 2005

Dig Deeper on Lotus Notes Domino Replication and Synchronization

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.




  • iSeries tutorials's tutorials provide in-depth information on the iSeries. Our iSeries tutorials address areas you need to know about...

  • V6R1 upgrade planning checklist

    When upgrading to V6R1, make sure your software will be supported, your programs will function and the correct PTFs have been ...

  • Connecting multiple iSeries systems through DDM

    Working with databases over multiple iSeries systems can be simple when remotely connecting logical partitions with distributed ...