I had a strange problem with documents that disappears in a replicated or clustered environment.
A more deep investigation lead to the discovery of deletion stubbs being created days/weeks/months before the document even was created, Strange. Documents getting create date the same as the original document.
But then a discovery was made .copytodatabase creates the same UNID everytime if the original document isn’t in the database. OK who cares the document isn’t in the database and no other document has that UNID. So far so good, but if you copy the document delete the new document in the new database. And copy it again, it gets the same UNID anyway. OK you might say, do this matter.
YES
It’s overwriting the deletion stubb on the destination database. If this database is in a clustered or replicated environment this will give your very very strange results. Documents disappearing, One minute they are there the next the documents are gone.
There is a notes.ini param that fixes the problem, but there is nothing in the documentation. And do we need a notes.ini to fix a bug? It should be the other way around if you built an application that uses a functionality based on a bug then you should need to apply the notes.ini param not the other way around.
To fix the problem apply the notes.ini param where your code runs client/server and you need to restart after applying.
CopyToDatabase_New_UNID=1
There is some other workarounds, one is creating a new document and using copyallitems. And the other one is copying the document two times but both these workarounds will give you problems if your document is large. So I would recommend the notes.ini param.
This problem should only affect LotusScipt code but after trying it out it works the same in XPages also.
0 Comments.