Issue:
Since at least Notes 11.0.1, there has been an issue with an Edit button not placing a document into edit mode in apps where document locking is in effect.
Custom apps of any complexity are being utilized where the application forms, and actions are updated to perform document locking. It never happens to custom applications that do not implement document locking - Apps not using the built-in LotusScript doc.Lock() and doc.Unlock() functions.
A user runs through an app view and clicks 30 to 50 Edit buttons on same number of documents, but then suddenly one will do nothing - no error pop-up, no status bar, nothing logged to the client even with various debugging enabled. (See below.)
Restarting the Notes client may or may not free up that document. After a period of time, the Edit button on that document would work again, and at some point later, within a week or two, a different Edit button would not work.
The issue occurs only on local replicas or other server-based replicas. The issue is highly intermittent and changes which documents are affected.
Issue occurs on both Mac and Windows "Standard" Notes clients. Although we did not extensively test beyond a few days, the issue could not be reproduced on the "Classic" client w/o the Java Eclipse client wrapper. We don't think this was conclusive as the issue would not show up for up to a week or two, and never for the same people. Other users can open the documents just fine that one or two other users cannot open. It seemed completely random. A Notes client on a laptop could open, but a primary workstation could not at the same location on the same network switch.
Issue has never been noticed to occur on the primary replica on the Domino server, but only on another server replica or a local replica of the application.
Mindwatering staff were were able to monitor communication at the primary replica on Domino server, when the local replica issue occurred. Wireshark showed port 1352 traffic for the successful documents going in and out of edit mode, but no traffic from the Notes client with one document which would not go into Edit mode. Although the issue gave the appearance of an intermittent networking issue, we were convinced the issue was more than networking after this point - any document's packets were transmitting, just not this "one" document.
Workaround:
Most of our Mindwatering users and our clients work and use the view preview pane. It was never noticed that this issue only shows up with the "Edit" button w/in the preview pane until a few days ago. One our very long-term clients encountered the issue yet again, and this time decided to open the document and click the Edit button there - it worked when the Edit button in the preview pane didn't work.
So when working in local replicas, when encountering the issue, open the document and then click the Edit button. Afterwards, you can get back to work without trying restarting the Notes client, or having to switch workstations.
Historical Notes on Debugging with HCL:
Mindwatering opened a couple of tickets for the issue with HCL. The last one was opened in 2025/03 and our client, Mindwatering, and HCL support staff worked diligently on it for a couple months and could not find any cause. We ended up just giving up.
The following debugs were enabled that showed nothing:
CLIENT_CLOCK=28
Console_LogLevel=2
LOGSTATUSBAR=1
DEBUG_CONSOLE=1
CONSOLE_LOG_ENABLED=1
NSD collected (leaving Notes running) showed nothing in the logs. It was decided that the issue had to be rogue networking issues.
Logs from the following folders were submitted:
- IBM_Technical_Support folder
- workspace/logs folder
Last Mindwatering HCL ticket mid 2025, CS1123753.
previous page
|