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)…
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:
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”:
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.
How to compare, contrast and edit Lotus Notes document field values with scanEZ
Thu, Jul 22nd 2010 6:39p Peter Woodford We’re always eager to hear how customers are using our software. Oftentimes folks surprise us with novel and creative uses we never would have thought of ourselves. But every so often, we hear from people who are so busy they haven’t had the chance to explore anything beyond the most immediate, hit-you-over-the-head noticeable aspects of the software (e.g. the Conflict Solver). This is truly a shame because the ‘just below the surface’ features are some of the biggest tim [read] Keywords: domino
lotus
notes
notes client
applications
database
interface
workspace
When the dreaded “Field is too large (32K)” Lotus Notes error strikes…
Fri, Apr 23rd 2010 1:05p Peter Woodford There are some problems in life—and in Lotus Notes—that defy easy solutions. And one such problem is the “Field is too large (32K)” error, which affects documents whenever the size of the Summary data for a field grows beyond the limit set in Notes*.
*The Lotus Notes Summary data limit is 32K for a single field or 64k for an entire document. See this Technote to read more.
The dreaded 32K error in Lotus Notes
When you encounter the 32K error you won’t be able to open the [read] Keywords: ibm
ldd
lotus
lotusscript
notes
rich text
database
java
