1
votes

I've been developing in Lotus (IBM) Notes/domino for something like 25 years and I've never come across this before.

The application is Notes client based, using Notes 9.

I open a document (DOC A) , which uses FORM A. From this document, there is a button to create a new document which uses FORM B. This opens in a new window. DOC B is not a response of DOC A, but some (a lot) of LotusScript copies fielse from DOC A to DOC B.

So now we have 3 windows open: The original application, the DOC A doc and the DOC B.

I make edits to DOC B, and save it. I close it, leave DOC A open, and navigate to another view where DOC B can be found.

Interrogate the Document Properties field list to see the field I edited ("InvoiceComments" in my case). Yep, my text is there.

Then I run a script agent which gets DOC B and prints up the content of InvoiceComments. It's blank. Write a Web agent to get same doc ... my text can be found in InvoiceComments.

It's definitely the same document, same UNID etc.

So that is: When looking at Document Properties, fields list, I can see myy edits in the field values. When running a script via Notes Client to get that document (either via UnprocessedDocument or from a view), the field has its 'old' value (blank)

The only clue I have as to what's going on is that if I close the DOC A, then all of a sudden the agent that prints "InvoicComments" value starts to honour what's on the disk (ie, it behaves).

Sounds like a bug in the notes client, but I'm at a loss as to how to get around it because people will want to do the process above.

2

2 Answers

3
votes

I had this some time ago when working with big script libraries and global variables.

I needed a LOT of debugging to find out what was wrong.

Essentially the problem is: As long as there is a variable ANYWHERE in the code that holds the document Doc A, then any script -run from whatever context- will get the "old" values of that document (despite the frontend showing you the changed item value).

Either Delete the NotesDocument- Object holding doc A in any code from doc B or use Set .... = Nothing to prevent that from happening.

So using either of these two lines will help:

Delete docA
Set docA = Nothing
1
votes

I can't take credit for this code, a consultant wrote it, but maybe this pattern will fix your problem:

Set doc=uidoc.Document
newentry=doc.CommentEntry(0)
id=doc.Universalid
Call uidoc.Fieldclear("CommentEntry") 
Call uidoc.Save
Call uidoc.Close(True)
Set doc=db.GetDocumentByUNID(id)
doc.CommentEntry=newentry

He found that even when you have a "valid" document object with a valid UNID, when you have it open as a UiDoc, Notes (frustratingly) keeps a copy in memory, so he had to resort to this idea. (Is it a bug or just a quirk?) I think this is essentially what Torsten is suggesting as well.