Situation:
In a workflow app (Notes client only) documents are routed between databases (dbA and dbB). This routing occurs in a loop, i.e.: docs are created / modified and approved in dbA then routed to dbB. If they need to be revised a copy of it is routed back to dbA, where it is modified and approved, then routed forward to dbB where it replaces its previous revision. This can go on and on in as many loops as revisions are needed.
With each revision a document link pointing to some other doc in dbB is programmatically created in the document’s copy which is routed back to dbA. After approval, when the main document is routed forward into dbB the doclink has to be removed programmatically again.
And here’s where the problems start: after some routing loops it CAN occur that the programmatically created doclinks are pointing to a non-existant document in dbA (instead of the one in dbB), or they even may be changed into a database link by some process unknown to me.
After some research I found out that the unexpected modification of the doclinks happen after the document has been edited and saved manually through NotesUI. I also found out that the internal “$Links” field is NOT created after the doclink has been created programmatically but only after the doc’s copy already containing the doclink is edited and saved manually. The links in the RT field however are working fine even if there’s no “$Links” field available.
The doclinks are removed using the NotesRichtextDolink.Remove() method, and until now I always had expected, that this method would truly remove the entire doclink. I had to find, however, that even after my code performs its Remove() method the document still contains the internal “$Links” field which still holds the old doclink.
Now, if I re-route that document back into dbA once again also creating a new doclink in the document’s richtext field, and then edit and save the doc through NotesUI I can see that “$Links” now actually contains two sets of link info, while the RT field only shows one doclink.
With each iteration this process is repeated invariably, and then after some loops the doclink info starts to change in a way that the replicaID part appears to be pointing to a different database. The amount of loops needed to reproduce that last bit is not predictable: sometimes it occurs sooner, sometimes later.
As a workaround I started removing the “$Links” field pysically which solves the problem in my particular case. This however wouldn’t be a solution if I was to maintain more than one doclink and then had to remove only some of them upon routing to dbB.
I’m aware of technote #1145216 / SPR #FBEEST6RNA but for one don’t think that it really compares to my situation. And on the other hand I don’t agree with the technote’s conclusion that this is not a bug: if there is a RichtextDocLink.Remove() method than I expect it to truly remove the link and all traces of it from the document, just as it happens with NotesEmbeddedObjects, for example. Otherwise the Remove() method wouldn’t make any sense at all.
BTW: I tested that behaviour not only in ND 8 but in ND 6.5 as well - same behaviour there.