PermaLinkDocument locking in Notes 6
posted Wednesday 15th, December 2004
 



In earlier versions of Notes, many of us have coded (or 'borrowed') routines to handle document locking and unlocking. It's typically a little messy - meaning that you have to put code in a number of places to ensure proper handling of locks. Well Notes 6 makes this all very easy. You simply assign an administration server to your database and then enable the database property to 'Allow document locking':

The only issue I've run across is that sometimes documents stay locked (for example, if a user's PC crashes). Notes does provide menu actions to unlock the selected document, but you have to know that it's locked. So what I do is to create a view to display locked documents, and a scheduled agent to run in the middle of the night and free up any documents that are still locked. The key is to know that the new system fields $Writers and $WritersDate are what control the locks. So the first step is to create a view with this SELECT formula:
SELECT @IsAvailable( $Writers )
The other step for the view is to add these 2 columns:
Column heading: "Locked by" ...column formula: @Name([Abbreviate]; $Writers )
Column heading: "Locked since" ...column formula: $WritersDate
It is then easy to see which (if any) documents are locked, and the date/time when the locks were applied. One can either manually research and unlock the documents as warranted, or it is easy to code an agent to go through the view each night and delete the $Writers and $WritersDate items from each document in the view, thereby releasing the locks.

This is so much simpler than the old way of handling document locking!
Comments :
 
 

1. Posted by Tobias Mueller - website09/09/2007 08:42 PM



Why are you deleting those fields instead of using the @DocLock ( [unlock]) function?

The document locking feature seems to have some problems:

1. http://tobias.olrato.de/archives/000184.html
2. Even if a document is locked, it can be copied within a view (for me this not ok)
3. If you have code that duplicates a document, it seems that in some cases the $writers and $writersdate fields are copied to the new document, which is then locked. (I'm currently working on this issue, so it's not sure why and when this happens.)





2. Posted by Joe Litton - website09/09/2007 08:42 PM



Tobias:
The reason I'm not using the @DocLock function is that I'd forgotten about it! It'd been so long since I'd reviewed all the new features (3 years, I think). As for copying within a view, there are so many problems I've seen with that, that I often disable copy/paste in views. I have a very simple routine that I keep in a script library and call from the Querypaste event of most views. It displays a message box informing the user that they are not allowed to copy/paste, and it tells them how to create a new document. I was not aware of the issue you've posted about profile documents if document locking was enabled, but I typically use author fields on profile documents, and so the issue would not have surfaced.

Thanks for the clarifications!



3. Posted by Christopher Byrne - website09/09/2007 08:42 PM



Joe,

I had posted this in the ND6 Forum some time back that is related to what you are saying:

http://www-10.lotus.com/ldd/nd6forum.nsf/55c38d716d632d9b8525689b005ba1c0/29ebd6a77aaed07685256dd00060db3d?OpenDocument

"I have recently had to deal with the frustration of Soft Document Locking on an application I was building which was causing fits for the way it was being designed (and for other legacy applications to be upgraded to ND6).

My scenario was that I was using a document link in the "About" document for the database launch. This document needed to be opened in edit mode because of how I was designing the Navigation in conjunction with Tabbed Tables. Of course once one person opened the document, the document was locked by the soft locking mechanism bult into ND6 (document locking was not enabled on the database).

As this was a non-starter for what I was trying to accomplish, here is how I did a workaround (I could not find one searching here), and would appreciate other people's thoughts, comments and feedback):

1. Set the database properties to allow document locking.

2. In the PostOpen event (for documents opening by default in Edit Mode) or the PostModeChange Event (for documents to be manually be put into Edit mode), put the following code:

Sub Postopen(Source As Notesuidocument)
Dim doc As NotesDocument
Set doc=source.document
Call doc.RemoveItem( "$Writers" )
Call doc.RemoveItem( "$WritersDate" )
Call doc.Save( True, True )
End sub

NOTE: The following will NOT work:

Sub Postopen(Source As Notesuidocument)
Dim doc As NotesDocument
Set doc=source.document
Call doc.UnLock
Call doc.Save( True, True )
End Sub

So far this has worked like a charm FOR MY SCENARIO and peopbably would not be the best approach for other purposes, such as "real documents" in a workflow. But this does look like it will save me much agony and many headaches. I will keep testing and post again if I find there are problems."

There is also a related technote at
http://www-1.ibm.com/support/docview.wss?rs=0&q1=1100606&uid=swg21100606&loc=en_US&cs=utf-8&cc=us&lang=en



4. Posted by Julian Robichaux - website09/09/2007 08:42 PM



I had a weird document locking problem a few months ago where 2 documents were locked, even though document locking wasn't enabled for the database. No idea how that happened. In fact, I didn't even see any $Writers fields on the docs, but every time we tried to edit we'd get the "Document Locked" message.

I ended up having to enable document locking on the database, then use @DocLock to unlock the docs in question, and then re-disable document locking.

I checked the forums to see if anyone else had experienced that, but didn't find anything, so I'm guessing it was an oddball error (it hasn't happened since).

- Julian



5. Posted by Tobias Mueller - website09/09/2007 08:42 PM



@Joe:
Using Authorfields in the profiledocuments will not solving this problem.
The author simply can not create a new profiledocument.