Notes Error:"The linked Document (UNID here) cannot be found in view"

That is a very easy problem to diagnose.. That issue occurs because the linked document cannot be found in the view  Causes for this issue can be that the document was deleted or that there was no "Default View" in the database at the time that the link was created.  It is best to have a default database view that has columns that you frequently use and a selection criteria that includes lots of documents in it.

yeah, thank you, yes, the documents have been deleted. We do have the 'Default View', how do we avoid this error? As there is a huge burden as we have re-create the documents manually and update from the correspond question(main document) and n number of (answers) document.

I use a button and a lookup instead of links where possible.  That does allow for the recreation of a document and the use of another key to use instead of the UniqueID.. a sample of what I have in the button looks something like...

Dim ws as New NotesUIWorkspace
dim uid as notesUIDocument
dim targetDb as notesDatabase
dim targetVw as NotesView
dim doc as notesDocument
set targetDb = ("ServerNameOfDbWithDocIWant", "PathToDbOfDbWithDocIWant" )
set TargetVw = targetDb.GetView( "SomeViewWithFirstSortedColumnBeingKeyIUse")
set doc = TargetVw.GetDocumentByKey( "UniqueKeyIUseInsteadOfDocID" )
if not doc is nothihng then
  Call ws.EditDocument( false, doc )
end if

Do you have a problem where the document exists in one replica but not another?  If that is an issue sadly the way doc links work is that it preferentially uses the replica the user has on their workspace and not the replica you want that has the documents.  If the user has more than one replica on their workspace it uses and impossible to predict or control methodology of seemingly randomly picking one replica, usually the least usefull one, and using it stubbornly making no effort whatsoever to look in other replicas.

Those dang document liks are a big pain in the butt.  We use URL Links instead of document links, with a URL link you can fix it so that you specify the database and server you want the link to direct you to instead of using a database UniqueID as part of the process.

If the issue is the document looking in the wrong replica then the answer is to let the users know that they need to remove the replica that you do not want the link to go to from their workspace.. absent the ability to do that you need to use intelligently created Notes URLS instead of doclinks.

If that is the problem then I have no idea how the document links got on the source documents and honestly do not want to code everything for you.  But you need to look at how the document links are being put on those other documents and change it so that instead of putting document links it puts Notes URLS that specify what database you want to send the user to.  This requires work, it requires you to understand what a notes URL is, what the parts of it are, and how to form one and put it where you want it.

if the issue is that the documents were deleted and do not exist anywhere then first and foremost how did you think document links would work with deleted documents?
taking a moment to really think about that, if you know documents may be deleted and recreated then you need to use a method that uses some other type of key field and either a button or a url that will get you what you want.

But look at your question.  The answer to your question is that the computer is telling you the document has been deleted because the document has been deleted.  The way to avoid that is to not delete the document.. OR use something other than a doclink..

and finally.. there is absolutely positively nothing in your question that would let me know this but.... it is possible that you want to restore documents from backup.. but somehow you are putting the documents back into the database in such a way that you are changing the document unique ID when you do it...  Don't do that.. Did you know that you can get the documents into a database and then set the DocumentID??? you can but there is a catch.. if there is a deletion stub in the database with that document ID it will fail.  This is way to complex for me to go into when your question does not even indicate that this is the problem.. but that may be a solution.

re: yeah, thank you, yes, the documents have been deleted. We do have the 'Default View', how do we avoid this error? As there is a huge burden as we have re-create the documents manually and update from the correspond question(main document) and n number of (answers) document.

Do not delete documents. Then there will be no error.

@larsenberntrop - Apologies for my delayed response. I thank you for all of your response. As for you suggestion on Replica, no Replication is not enabled. Users use only the Server. We do have a view to capture the documents that are deleted. The option of taking the document from the backup is also not feasible as its deleted within 5 days time, in case the user comes back late. Yes, we do re-create a new document and use yet another code to paste the newly created document link on to the source document. The Universal ID is re-set, it does work.  But, its a tedious task though, hence was looking for a better approach towards resolving this issue. Most of the help that is available states that the reason for this particular issue is related to 'Replication', but in this case, 'Replication' is disabled. Hence, I was just trying to figure out and avoid the root cause of this issue. Roles are enabled for deleting documents, not sure, how the documents are deleted. Will surely, look how to avoid the access to delete. In case you have anything more to share on this. Please do let me know. Thanks a lot for the above response.

Deletion rights are withheld via the ACL.

If you want be absolutely sure about deletions, make sure only a specific ID or group of IDs can perform a delete.  You can even withhold delete rights from someone with Manager level acces to a database.

I need to work on the code as suggested.

Hi,

What happens to deleted documents when Replication is not enabled.  I mean, the deletion stubs? How will this be handled by Notes? Sorry, please let me know, if I have to open this as a new questions.

Regards,
Shalu

We have also seen this issue, when a user had access and delegation setup and the meeting request is auto forwarded to the person(PA) so they can action. eventually they can can get to the document which doesnt make sense to me.
Currently investigating this.

the deletion stubs will be purged according to the4 Purge Interval. (When this happens in the Notes client you see the message Reclaiming unused space in the statusbar)
The Purge Interval is one-third of the setting: "Remove documents not modified in the last xx days", set in the Space Savers tab of the Replication Settings of a database.  To acces built in help, go to the replication Settings, go to the Space Savers tab, and click on the Question mark (?) in the title bar of the Dialogbox.

Note that the Purge interval is related to the number of days set, DO NOT enable the "Remove documents not modified in the last xx days" setting unless you really want to!!!

To get rid of deletion stubs, as you seem to know you change the number of days that you "Remove documents not modified in the last XX Days setting".   If you have a checkmark in the box you will delete all of your documents.  So it is VERY IMPORTANT not to have a check in that box.  If you change that number to 0 and then compact the database you will get rid of the deletion stubs in the database.

@behenderson - What happens Replication Settings - is disabled?  Inspite of Replication Settings disabled the properties in 'Space Savers' tab still works for deleted documents is it?

yes. That's why it is not very obvious