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.
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
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.
Related
Basically what I want to do is create a form whilst within another form and pass values from the earlier form to the second. Complicated I know but here is what I got.
#Do(#Command([Compose];"LPK"); #SetField("PR_Make"; PR_Make))
The fields in both forms have the same name and this code is called when first document is attempted to be saved.
I think instead of editing the field on the second form it just saves a field as itself instead. Any help appreciated.
The best and common way is to enable form property "Formulas inherit values from selected document" in second form "LPK".
Add a default value formula to second form's fields you want to inherit and put just the name of field itself in. For your example default value formula it would be
PR_Make
Make sure you save document first and then create the new document.
Knut Hermann's answwer is the 'standard' way of achieving such things but there are other methods- eg you can use environment variables ..
Something like:
#Environment("PR_Make") := PR_Make;
#Command([Compose];"LPK");
Then set the default value for PR_Make in your new form as ..
#Environment("PR_Make")
FYI Environment variables are written to the user's Notes.ini file and so remain even after Notes has been closed and re-opened. #Environemt doens't work too well with Web applications as it uses the server's notes.ini.
An alternative would be to use profile documents:
#SetProfileField( "PRDefaults"; "PR_Make" ; PR_Make;#Username);
#Command([Compose];"LPK");
.. in the default field for PR_Make on new form :
#GetProfileField( "PRDefaults"; "PR_Make"; #Username);
Profile documents are stored as a kind of hidden document in the Notes database and persist with the database. The last parameter sets a further subdivision by username so each user gets their own profile doc - a bit like a personal profile for "PRDefaults". You can miss this last parameter #Username out, to have one profile doc per database but there's a risk of two people trying to use it at the same time and clashing.
Profile docs also work with web applications.
I followed this link enabling me to setup a hotspot in a richtext field - works like charm.
http://ozinisle.blogspot.de/2010/11/lotusscript-code-to-append-hotspot-to.html
Only problem is, as the user(s) usually do(es) not have deletion rights, the document created by the import stays stored in the database. In LotusScript e.g. I can create a new temporary document and work with it, and if I'm not saving it, it just disappears at the end of the function.
Is there a similar way or parameter for DXL import which allows me to just drop the document after I got my rtitem?
Alternatively, can someone point out to me if it is possible to create only the temporary richtext item in/on a document I created as tempdoc via LotusScript?
My search on the web did not get any results and my tries to reduce the linked function always resulted in the error 4518 (which is described in the help document of "DXLImporter"); if I read the help right, the DXLImporter only supports the db as valid output (thus expecting documents being created via DXL).
I don't see a way to import DXL without creating a document.
The easiest solution is to create the temporary document in users "cache.ndk". The user has definitely the right to delete documents there. So, you'd replace the line "Set db = session.CurrentDatabase" in code you linked to with
Set db = session.Getdatabase("", "cache.ndk", false)
The rest of the code would stay the same.
As an alternative, use the more classic approach running an agent on server to delete the temporary document. Create an agent which deletes the document, set property "Run on behalf of" to someone who is allowed to delete documents in database and call the agent from your script with
agent.RunOnServer(noteID)
I have a strange problem: I want to access documents in a different database (same server). My approach is very close to this one discussed here: http://www-10.lotus.com/ldd/nd85forum.nsf/DateAllFlatWeb/517ef6249d5b9fa6852575cc00503786?OpenDocument
I have only 3 docs in the source database. 2 are created directly, one is copied from another database (these are just test document). We have a generic view that lists thos entries from a view, calcs the links in a form like this:
http://localhost/database.nsf/xpMBK.xsp?action=openDocument&db=dominotest%2Ftest%2Fulcbs%21%21projects%2FFKIE%2FEinsMuB.nsf&view=AMBKEinsAll&documentId=781F14A98A699548C1257C3200316BAC
As you can see we are using an Xpage in the current database and place parameters that point the Xpage to open the document to the source database (notation is server!!database here), a view (this is the one to which I want to return) and finally the unid of the source document.
Now the strange one:
I cannot open the copied document, receiving the
NotesException: Invalid universal id
lotus.domino.local.Database.getDocumentByUNID(Unknown Source)
error.
Even better: if I copy a document that works within the same database (the current one) this document can also not opened anymore!
What's this and can you give me a hint to solve this?
Thanks in advance!
If, by "copied", you mean either manually copied and pasted into the target database or programmatically duplicated via copyToDatabase(), the new copy of the document will be assigned a new UNID; it is not guaranteed to have the same UNID as the original did (and, in my experience, it's rare that it preserves the original). If you're duplicating the document programmatically, be sure to check its new UNID afterward and use that ID in your URL calculation instead.
I've had a problem very similar to this in the past, and the answer turned out to be that I wasn't opening the NSF file that I thought I was opening. I was using NotesDatabase.OpenByReplicaID, and there were two replicas of the database on the server, with different sets of documents. In that situation, Notes gets to pick one of the two replicas -- you have no control over it. The replica that was actually opening contained some of documents corresponding the the UNIDs that I was trying to access, but some of them really were not there and therefore the getDocumentByUNID() method was correct in throwing the "Invalid universal id" error. This was really, really hard to debug.
After I figured it out and removed the second replica from my server, the first thing I did (after testing and confirming the problem went away) was to write an agent that scans a server for duplicate replica IDs.
The UNID:S in a Domino database when it's copied to the database thru copyToDatabase is done like this.
One part of the UNID comes from the database one part is document unique. So if you copy a document from one database to another the document could get the same unid each time. If the unique combination doesn't have a valid document with that combination in the database, the document will get the same UNID everytime. In other cases the document will get a new Id.
More information can be found here
UNID and copytodatabase
Thank you guys for your ideas!
But I was completely wrong #facepalm
The problem was: a colleague coded a bean to access the other database and I didn't noticed that the config document pointed to a replica on another server, so when I copied the document within my database on my local server it was fairly clear that the xpage could not find the copied one - as it resided on the other machine.
Thank you anyway :)
After I create a doc in a Notes app, I'm moving information from that doc to a postgres db.
The agent that transfers the data to postgres uses a field in the doc as the key field.
I'm running into the following problem:
- If I create the doc via the Notes client, the transfer occurs without problems.
- If I create the doc from an agent (which processes an incoming email and generates a valid key field value), the transfer fails with a null key error. If I then open and save the doc, the transfer is successful.
I key field value is not null, however. I can see it in the view, in the document, and in the document properties.
Any thoughts on how I might be able to figure this out would be appreciated.
thanks!
clem
============================
Thanks Torsten for the reply. I appreciate it. Well, there's not much to the code, really. Here's part of it. "x.LogNumber" returns a string. The format is something like T1234CP. I ended up adding the computeWithForm and setting the IsSummary tho I don't think it was necessary.
atdoc.logNumber = x.LogNumber
Call atdoc.computeWithForm(false, false)
Dim lnItem As NotesItem
Set lnItem = atDoc.getfirstitem("logNumber")
lnItem.IsSummary=True
Call atdoc.save(True, False)
=======================================
Once the doc is created, an agent runs that transfers some data from the doc to the postgres db via odbc:
'.. define the 'key field' to be use in the connection.select call
Dim selectFldLst As New LCFieldList
'.. add the key field name to the LCfieldList object.
Call selectFldLst.Append(NotesKeyFieldName, LCTYPE_TEXT)
'.. set this field to be the key field.
selectFldLst.Getfield(1).flags = LCFIELDF_KEY
Set Notes_LCFieldList = New LCFieldList ' flSrc
Set odbcDB_LCfieldList = New LCFieldList ' flDest
'.. get the key of the doc to transfer.
Set docWithTransferID = docsToTransferViewEntry.Document
selectFldLst.LogNumber = Trim(docWithTransferID.stid(0))
count = Notes_LCConnection.Select(selectFldLst, 1, Notes_LCFieldList)
^--- This selects the fields from the Notes document. This is where it fails. It returns 0 for 'count'. It should return 1. If I save the document manually, it works.
Sounds like your form is doing something to it. As a quick and dirty fix you could try doc.computeWithForm() in your agent before saving.
You create the records from Notes? Save yourself the trouble with code in the events and configure DECS. It creates the document for you reliably.
Most probably the items in the document you create do not have the "Summary" property set. That makes them "invisible" for some functions / subs...
Please provide some code about how you create the items. If you do it like Set item = New Item(doc, "Name", "Value") then the item will not be summary. Then you need to call a item.issummary = true
Taking into account the last comments I guess, that the agent sets the item with the wrong datatype. Again: The code of the agent would have helped to identify this.
If for example the Field in the document is of type text and the agent writes something like
docWithTransferID.stid = 1 then everything "seems" to be OK, as the field is shown correctly in the views and in the Form. But in the Properties of the document it will be shown as number. As soon as you save the document, the design of the form will force it to be a Text.
The same thing works vice versa. If the agent reads the data from a textfile (e.g) and does something like docWithTransferID.stid = "1", then the item will be text, no matter how it is defined in the Form. As soon as you save the document -> Voila, it will be a number again.
Background LotusScript does not know ANYTHING about the Form and therefor does not obey datatypes or formats... You have to take care for this yourself.
I have a SharePoint document library I am working on. It has a list of document sets. Each document set has a few fields that are marked as "Shared" so that they can be inherited by the documents inside.
When I upload a document inside a form opens and all the fields on the form are pre-filled with the shared values of the corresponding columns. But when I use create document from template, it opens the template in the corresponding Office application but the document property fields are empty and not read-only which is against the requirements of this project. I require them to be synced and filled exactly like when a document is uploaded.
There is one thing though. The user can fill any value he wants in those fields and they will still be saved a synced copy from parent in the library discarding what the user filled in, which is good, but why not show those values up in the document in the first place?
Anyone has experience in handling this please help. I have searched a lot on the internet but either my keywords are wrong or no one has had this problem before.
SharePoint version: 2010 Server
Office version: 2010 Professional
It sounds like you need a simple event reciever, which fire on itemadded. It would then go back up the tree to find the document set. Capture which properties are marked as shared. Adjust the item that is being added to force the values.
Probably 8 lines of code