Subject: RE: Time to debug replication?
This might be related to an issue I had long ago …
Yes, I ran into this as well. The solution is NEVER to use cut and paste to replace design elements in a database that’s updated by a template. Doing this deletes the old form, and creates a new one with a new document number. The next template refresh gets very confused by this, deletes the “new” document, and tries to replace the old document. This seems to work until someone with designer access replicates, and that really confuses Notes, breaking the application.
I’ll copy my old note to my co-designer below … figuring this out took several days, and could not have been done without NotesPeak 
Whew … after digging into the depths of the database with NotesPeek (a wonderful tool) I now know exactly what’s going on, and how to easily fix it.
When Notes does a replication, it needs to know what has changed in order to move those changes from the server copy to the local copy. The key to the problem we’ve been seeing it that it does NOT use the date/time of the change to decide this, but looks at each document’s sequence number. This is a number that’s incremented each time a document is changed.
What’s causing us trouble when Pasting forms into the production database is that we delete the old form, and the local replica sees that, and deletes it’s local copy, as it should. When we then replace the production design, the copy is deleted, and the original is “reactivated”. The problem is that when this reactivation happens on the server, Notes decrements the document’s sequence number. (I don’t know why).
This causes the local replica to ignore the reactivated form, since it’s sequence number for that document is greater than the server copy. Here’s an example.
Action
Template database
Server Database
Local Replica
Notes
Starting situation.
Original Form, sequence = 9
Original Form, sequence = 4
Original Form, sequence = 4
The Template version has been saved 9 times, but has only been Replaced in the server copy 4 times.
The form is changed.
Server copy is Replaced.
Local replicates.
Original Form, sequence = 10
Original Form, sequence = 5
Original Form, sequence = 5
As expected
The form is changed.
It’s Cut-&-pasted into the server copy, and the one that was there is deleted.
Local replicates.
Original Form, sequence = 11
Original Form, sequence = 6,
Marked as deleted
New Form, sequence = 2
Original Form, sequence = 6,
Marked as deleted
New Form, sequence = 2
The old form still exists as a Deletion Stub, and a new document is created by the Paste action.
The form is changed.
Server copy is Replaced.
Local replicates.
Original Form, sequence = 12
Original Form, sequence = 5,
Reactivated
New Form, sequence = 3,
Marked as deleted
Original Form, sequence = 6,
Marked as deleted
New Form, sequence = 3,
Marked as deleted
Note that when the server reactivated the original document, the sequence was decremented. Thus, it’s NOT copied over by the replication.
The reason that a Cut and Paste will not work, and would probably re-cause the problem is this.
The TEST system has an IE form with a particular Universal Notes ID in it. (The “AC86DC19C9125EDE8525682C005EDB59”)
When we do a Design Refresh, this number is carried over into the Production System, and then down to the Replicas.
If, in the production system, you Copy the form, delete the old one, and paste it back in, you are deleting “AC86…” and creating a new document, say “FFAA…”. When someone replicates, this is carried down to the replica.
So now in the Production and Replica system, we have AC86… as a deletion stub, which was the original IE form, and FFAA… as the new IE form. At this point, everything still works.
Now we do a design refresh. The system sees that there is a form in the TEST system, called IE, with a code of AC86… and a different IE form in the production system called FFAA… It assumes that the TEST system is correct (as it is the “master” copy) and so deletes the FFAA… form, and copies back in the AC86… form. So now the original is back, and the pasted version is deleted.
The problem comes in when we replicate. The replication process sees FFAA… as being deleted, and so deletes the same form in the local copy. It then looks at the AC86… documents, and sees the Sequence number in the Replica is greater then the Sequence number in the Server copy, and so assumes that the Replica is more recent, and thus “correct”.
And it’s just hit me that if you or I replicate back (having designer access) the replication process is going to delete the SERVER copy of AC86… and then the Production copy is now broken (Very Nasty).
So the bottom line is : Don’t paste into the Server copy. Always do a Design replace from the Test system, and so keep the original Universal Note IDs the same in the Production and Replica copies.