Is Lotus Notes SCHIZOPHRENIC?

HCL Domino Domino Forum
1

We experienced very strange problem and nobody of our developer team has explanation for this simple problem:

We have action “Process Document”, which changes the value of the field Processed from empty string “” to “OK”:

doc.Processed = “OK”

Call doc.Save (True,True)

We have View to see all documents, both processed (“OK”) and unprocessed (“”).And now what is strange:

If we later run any agent on any recently ‘processed’ document using coll = db.UnproccessedDocuments and set doc = coll.GetFirstDocument, command doc.Processed(0) returns always empty string and not “OK”!

BUT:

If we access the very same document in same view with Set doc = session.DocumentContext, the command doc.Processed(0) always returns expected value “OK”.

In Document Properties is the value in Processed field also “OK”.

We also found, that if we restart LN Client (not only database, but entire Lotus Notes!), the agent returns correct value “OK”!

This issue was tested with same results on all R6 clients and servers (6.0 - 6.0.3.)

Question: Can somebody explain, why the agent returns on ‘processed’ documents empty string and not “OK” as expected? And why it works after LN client restart?

Thanks for any help!

2

Subject: Is Lotus Notes SCHIZOPHRENIC?

I do not know if and how you solved that problem, but a uidoc.close behaves different from what a designer is expecting to do.If you use this function the uidoc is closed but NOT unloaded, until the client is closed. Lotus brought a new parameter in with version 5.0.8 or 9 wich is referred to in the online help as immendiate

Call notesUIDocument.Close( [ immediate ] )

This Parameter is boolean and if set the document is closed immediate. The Default here is false.

3

Subject: RE: Is Lotus Notes SCHIZOPHRENIC?

Hi ,

I think I am looking at a similar kind of problem in my application. I am using the EditDocument API with the options

EditDocument(false, notesDocument, true, “”, true, false).

Code structure is as follows

Domino.NotesDocumentCollection coll = db.AllDocuments;

Domino.NotesDocument doc = coll.GetFirstDocument();

documentCount = coll.Count;

for(int i = 0 ; i < documentCount ; i++)

{

try

{

//----- code truncated here —//

//--------------------------------//

// The below EditDocument method calls the late-binding Lotus // Notes method call: NotesUIWorkspace.EditDocument

EditDocument(false, notesDocument, true, “”, true, false).

//----- code truncated here —//

//--------------------------------//

}

catch(Exception ex)

{

 if(i < documentCount) continue;

}

finally

{

if (notesDocument != null)

								{

									if(Marshal.IsComObject(notesDocument))

									Marshal.ReleaseComObject(notesDocument);

									notesDocument = null;

								}

}

}//end of For Loop

if (coll!= null)

{

// Explicitly release the COM object created by CreateViewNav.

// This must be done or memory will not be deallocated.

Marshal.ReleaseComObject(coll);

coll = null;

}

//Code Structure end here

I also make sure that the NotesUIObject that I have initialized is appropraitely closed using the latebinding call to Close().

Everything works fine until an exception is encountered while calling the late binding NotesUIWorkspace.EditDocument method . Even if a continue statement is written ( though not needed as the for loop must continue till the end of the collection ) all the documents following it have the same problem as though "that one document that caused an exception has caused some flag to be set and after that all the followinf documents end up as exception " .

Please let me know if you have found a solution to it.

4

Subject: Lotus Notes SCHIZOFRENY

Martin,

You should be using the following:

Call notesSession.UpdateProcessedDoc( notesDocument )

See the example in the Designer Help file

Please report if this made a difference.

Ed Pulido

5

Subject: RE: Lotus Notes SCHIZOFRENY

Dear Ed, we run agent against SELECTED documents in view and UpdateProcessedDoc method (as described in help) is required only “For agents that run on new and modified documents, newly received mail documents, pasted documents, or newly modified documents”.Nevertheless,we tried to use it even if it is not our case, and - it did not help.

6

Subject: I’ll take a stab at this…

I think what you are experiencing is a function of the difference between what you see in the view and what “order” the documents are in when you call db.unprocesseddocuments.

I bet the collection of unprocesseddocuments is not in the same order you see them in the view and thus you are simply looking at the wrong document when you set doc = dc.GetFirstDocument

Can you prove that the first doc is the doc you are looking at in the view?

Just a thought. Forgive if I’m way off base.

  • Matt
7

Subject: RE: I’ll take a stab at this…

Yes, Matt, we considered this option too, but it is definitely the same document (we compared doc UNID to be very sure). Thanks for your post anyway.

8

Subject: IsUIdocOpen = TRUE ???

We found new interesting fact which can be related to above described issue. In the ‘Process Document’ action is document opened on UI with EditDocument method and at the end is closed using UIdoc.Close(). All value changes are done on backend using doc.Field = Value and doc.Save.

If you go back to view and check property of recently ‘Processed’ document doc.IsUIdocOpen, it always returns TRUE (although the doc is NOT opened in any UI window) unless you restart entire LN client. (reopen database do not have effect, doc is still reported UIdocOpen=TRUE).

Can somebody explain, why any doc closed from UI either manually by user, either using UIdoc.Close(), is ‘forever’ reported as UI opened??? How to REALLY close it? This will explain and solve our problem described at top of this thread

9

Subject: RE: IsUIdocOpen = TRUE ???

I have seen this behaviour in R5 databases.

There is a serious flaw somewhere in the notesUIWorkspace.editDocument(True, doc)

The “old version” of the backend document being edited is somehow cached in memory in the view context. Possibly being held alive by a reference to the document, a parent notesSession or NotesUIWorkspace in the view Globals or elsewhere.

Any future reference to this document will return the cached document, with the previous values. This document should have been garbage collected thus forcing the document to be re-fetched from the database.

I have experienced RBODs (Red Box Of Death’s) being caused by this, too.

One workaround that seems to consistently fix this problem is to remove the memory reference to the notesDocumemnt after the call to editDocument, like so:

Dim ws as New NotesUIWorkspace()

Dim uiDoc as NotesUIDocument

Dim doc as NotesDocument

…

set uiDoc = ws.editDocument(True, doc)

Delete doc ’ forces garbage collection of doc object

Try it and let me know whether this clears the issue.

10

Subject: ws.Editdocument & LS code in QueryOpen/PostOpen

I noticed that “serious flaw” in ws.EditDocument a while ago using R5.

In my experience, it was not “caching” the old (ui)document, but “picking up” the old uidocument.

This was caused by LS code in the PostOpen event of the newly opened document:

The LS code used “uidoc = uiworkspace.Currentdocument” and this somehow picked up the PREVIOUS document.

Very hard to debug, this issue, but once or twice I actually could see the wrong reference in the debugger (most of the other times it crashed).

Changing the LS code to use the “source” parameter of PostOpen (or QueryOpen) solved the problem.

Point of the story: use the Source parameter whenever you can, use uiworkspace.currentdocument only in buttons etc. (and you could use a global parameter initialized in PostOpen even then).

Hope this helps someone…

11

Subject: Delete object did not help!

Morten, thanks for tip, but it did not solve the impotence of our agent. We share your feeling that all documents once opened to UI with EditDocument method are somehow ‘cached’ and since that moment Lotus Notes becomes schizophrenic - in the view actions or agents using db.UnprocessedDocuments you see different “copy” of document than if you access them via other methods. Unfortunately, Delete object did not help to stop this serious psychic disease of Lotus Notes. We are very afraid that it is some far-reaching bug deep in code of Lotus Notes client. We also experienced many NSD breakdowns while exploring this issue, what supports this shocking hypothesis too. It makes however all applications using UI classes vulnerable to heavy heavy troubles :((((

Note: See also this thread http://www-10.lotus.com/ldd/46dom.nsf/55c38d716d632d9b8525689b005ba1c0/6c6872471112c1a585256b5a004c9dc6?OpenDocument

12

Subject: What about other object references, then?

Do you have any code in the view iteself (view events or Initialize) that keeps a handle to a notesSession, notesUIWorkspace or notesDoument object while the document is being edited?The reason I ask is that I had exactly the same symptoms as you (+ red box of death), about a year ago, and could reproduce at will, but fixed the problem by clearing object references that were being held alive in the view.

13

Subject: Problem exists in any view

Morten, our view has no extra code in its events, so there are no object which could be deleted. There is only View selection condition. We went even further and created same view de novo in order to confirm that our problem is not affected by ‘somehow’ damaged view. As we tested, our issue is easily reproducible in any new database! We believe that view itself is not a source of troubles,but the way how Notes Client operates with UI opened documents in memory.

14

Subject: RE: Problem exists in any view

OK, I have one more suggestion for you.

Try opening a document with a “minimal” form (i.e. no LS code on the form), to see if the problem may be caused by code on the form.

If that doesn’t solve the problem, I suggest you create a tiny database with just enough design in it to reproduce the problem, and send it along with a formal bug report to IBM. It’s a bit tedious, but worth it.

Sorry that my hints didn’t turn out to solve your problem.

15

Subject: RE: Delete object did not help!

Dears, I just read your whole and very interesting and in my opinion also important discussion. If it is true, it is in my opinion the same bug which causes crashing every client lotus notes.

I have very simple form. This form is filled in by user and during recalc and querysave I have there some operations on background. There is an action on the form with three commands :

@PostedCommand([FileSave]);@PostedCommand([FileCloseWindow]);@PostedCommand([Compose];“recorddoc”)

Looks very simple, save document, close and compose newone - the same one.

If user creates several of these documents (using several times this button), LN client will crashed EVERY time. But not everytime after the same number of clicking. It also depends on free memory of the computer. So in my opinion it can be the same problem that noteuidoc is still in memory and there is no memory refreshing - restoring mechanism.

Is here normaly someone from Lotus Developers reading this forum?

Best regards

Petr