Either it isn't database corruption, or the steps suggested didn't fix the corruption.

I ran the suggested commands on one of the databases to completion, and then tried compact -a on it, and same error.

"Error archiving documents from mail\xxxxx.nsf: Entry not found in index"

Any other ideas?

Here is output from console when trying to run archiving from the server. Debug level 10
The mail file is at \mail\xxxxx.nsf
The archive file is at \archive\a_xxxxx.nsf
Archive settings are to archive on the server - filenames look like they match.

load compact mail\xxxxx.nsf -a
[03A0:008A-0428] 11/27/2015 02:23:41 PM  Remote console command issued by xxxxx: load compact mail\xxxxx.nsf -a
[1730:0004-1EF4] 11/27/2015 02:23:43.46 PM Archiving> Calling NAMEGetPolicy for CN=xxxxx/O=POWER&MINE
[1730:0004-1EF4] 11/27/2015 02:23:43 PM  Archiving documents from mail\xxxxx.nsf (xxxxx)
[1730:0004-1EF4] TestNoteForArchiveSelection> Adding note 624738 (98862) as entry 158
[1730:0004-1EF4] TestNoteForArchiveSelection> note 624734 (9885E) is deleted/ghosted
[1730:0004-1EF4] TestNoteForArchiveSelection> Adding note 624742 (98866) as entry 159
[1730:0004-1EF4] TestNoteForArchiveSelection> Adding note 624746 (9886A) as entry 160
<snip> lots of similiar entries - no errors, then...
[1730:0004-1EF4] 11/27/2015 02:23:49.78 PM Archiving> Adding parent id 612814 of noteID 612818 to Ancestors
[1730:0004-1EF4] 11/27/2015 02:23:49.78 PM Archiving> create time of note 612814 (0x959CE) is 04/07/2011 05:39:10 PM
[1730:0004-1EF4] 11/27/2015 02:23:49.78 PM Archiving> create time from criteria is 11/27/2013 02:23:43 PM
[1730:0004-1EF4] 11/27/2015 02:23:49.78 PM Archiving> note 612814 (0x959CE) is a candidate based upon create time
[1730:0004-1EF4] 11/27/2015 02:23:49.78 PM Archiving> ARCHIVE: adding noteID 612814 to Match
[1730:0004-1EF4] 11/27/2015 02:23:49.78 PM Archiving> create time of note 612826 (0x959DA) is 04/08/2011 06:59:37 AM
[1730:0004-1EF4] 11/27/2015 02:23:49.78 PM Archiving> create time from criteria is 11/27/2013 02:23:43 PM
<snip> lots of similiar entries - no errors, then...
[1730:0004-1EF4] 11/27/2015 02:23:50.26 PM Archiving> Error getting archive notes: Entry not found in index
[1730:0004-1EF4] 11/27/2015 02:23:50.26 PM Archiving> Error selecting documents for archiving, pruning and deleting: Entry not found in index
[1730:0004-1EF4] 11/27/2015 02:23:50.31 PM Archiving> Exiting V6 archiving process
[1730:0004-1EF4] 11/27/2015 02:23:50 PM  Error archiving documents from mail\xxxxx.nsf: Entry not found in index
[1730:0004-1EF4] 11/27/2015 02:23:50 PM  Compacting mail\xxxxx.nsf (xxxxx),  mail\xxxxx.nsf -a

Try changing archive selection criteria. I got rid off error after changing from "older than" to "not modified in more than". Also archiving worked then manual selection of views or folders.

@Vytautas Norvaisas Thank you very much for the solution!!!!

BR

Dagan Keysary

We're facing the same issue here since 9.0.1 is in production. What I can say so far: There are meeting related documents which have no or a a damaged "creation date" (view the document's property: Creation date is blank). Why? No idea so far.
Please find below the Lotus Script code we send as button within a mail to the affected users. Afterwards users have to check the documents found to not delete any meetings in the future from their calendar. After deleting all damaged documents, archiving is working again.

' Lotus Script send as button within a mail

Dim s As New NotesSession
Dim viwApptUNID As NotesView
Dim docol As NotesDocumentCollection
Dim doc As NotesDocument


'    Set viwApptUNID
Set viwApptUNID = s.CurrentDatabase.GetView("$ApptUNID")
If viwApptUNID Is Nothing Then Msgbox "Cannot find view '$ApptUNID'"

'    Set docol
Set docol = s.CurrentDatabase.CreateDocumentCollection

'    Loop through all docs in view
Set doc = viwApptUNID.GetFirstDocument
While Not doc Is Nothing
If Instr(Join(Evaluate("@Text(@Created; S2)", doc)), "*") > 0 Then Call docol.AddDocument(doc)    ' @Created is save here, Document.Created sometimes delivers a date valid formatted but containing crypted components
Set doc = viwApptUNID.GetNextDocument(doc)
Wend    ' Not doc Is Nothing

'    Handle result
If docol.Count > 0 Then
Call docol.PutAllInFolder("aaa_BAD_CreationDate")
' Call docol.RemoveAll(true)    ' Hard deletes all documents found. Used only in case the documents cannot be deleted through UI
Msgbox Cstr(docol.Count) & " damaged calendar entries found and moved to folder 'aaa_BAD_CreationDate'"
Else
Msgbox "No damaged calendar entries found."
End If

The issue is caused by document that are missing a creation date when an archive condition "older than xxx" is used.

Typically calendar updates from external sources are affected, I suspect a bug in the iCal conversion routine.

@Alexander:

Using "not modified for 6 month" will work fine for you, you don't have to worry about old calendar entries being archived. The only difference is, that the cut-over date is less precisely calculated.

Using "older than" or "not modified for" makes basically no difference. Anything older than the cut-over age is archived, which is simply calculated in a slightly different way.

Being archived does not imply being deleted from the archived database. To be deleted after an archive run, the document must match several conditions:

- It must not have child documents that are not also archived (replies, calendar repeats and so on),

- It must not have a $NoPurge Field set. $NoPurge contains a target date how long the document is required in the database

- It must not be a design element, ACL entry or profile document. These are always archived and never deleted.

Stationaries, rules, documents marked for follow-up, repeating calendar entries and other persistent documents have $NoPurge set to indicate the earliest possible archiving date.

In your example, the repeating calendar entry will be archived after 6 months but not deleted prior to its end date plus 6 monts (the time set in the archive condition). You simply find it in the main db and in the archive simulaneously.

However your script is helpful to fix affected databases. Since you permanently have to monitor the archive process for "entry not found in index"-errors, I prefer to use "not modified for"-conditions.

When I import calendar entries from ics files, the new entries do not have a creation property.

I have the same problem with Notes-client 853FP6 and Notes 901.

Today I reported the problem to the ibm support.