How *often* you click Ctrl+S can affect Lotus Notes application development

ctrl-s

Continuing in our series of Lotus Notes secrets, we’d like to share a strange little tidbit about design element replication (this is one of the secrets that Ytria’s Eric Houvenaghel shared at his Lotusphere 2010 BoF session):

A tale of two Lotus Notes developers

Once upon a time two developers were each working on their own local replicas of the same Notes application.

One developer, we’ll call him Bob, was nervous about losing changes so he clicked Ctrl+S after every single change he made.

The other developer, who we’ll dub Henry, was a bit more laid back. He only saved his work periodically, after significant changes were made.

Now the problem:

Naturally enough, Henry and Bob would sometimes get their wires crossed and work on the same design elements at the same time. And since Designs can’t have conflicts, someone’s work would inevitably be lost after replication. But oddly, in these situations it was always Henry’s work that got lost–even if he was the last one to work on the design element in question.

But why?

Because every time Bob clicked Ctrl+S the sequence number would go up and it turns out that a higher sequence number trumps a more recent Modified date in design element replication.

Still don’t believe me?

For all you doubters out there, I performed a little experiment with scanEZ to confirm our observations (I used scanEZ because it lets you have multiple open sessions with different active IDs).

First, I did some modifications to a view being sure to save frequently, thus running up the sequence number (see the image below)…

note info

Image A: The Ctrl+S Maniac

Next, I performed another modification on the same design element on a replica of this database using a different ID. This time I only saved once. But notice in the image below the Modified date is more recent than in the image above:

more-recent

Image B: The changes are more recent but the dev saved his work only once

When I replicated, as expected, the version in Image A was the “winner”:

after-replication

The “winner”

How to avoid this issue

A locking solution that prevents developers from working on the same design element is probably the simplest way to prevent this problem from occurring in your Notes shop.

Privacy Preference Center