When a parent note is created in a Domino Database after one or more of its response note(s), the parent note is not visible until fixup is run against the database.

when a parent note is retrieved by IBM CSLD after one of its response notes has been retrieved, the new parent note is not visible until fixup is run against the database, e.g.:

· It does not appear in a “All Documents” view
· Programs that use the Notes C API call “NSFDbGetModifiedNoteTable” do not get the noteid back in the resulting ID Table ( using wildcard time cutoff )
· Database properties “total document count” does not include it

However, if you know the UNID of the note that has been created, searching for it using NotesPeek or via Notes C API calls “NSFDbGetNoteInfoByUNID” or “NSFNoteOpenByUNID” does find the note.

Our investigation indicates that what appears to happen when the response note is added to the database before its parent:

1. Domino creates some sort of dummy entry in the database UNID table for the parent UNID
2. Domino allocates a NoteID for the parent note in the database
3. Domino then creates/stores the response note (adding UNID to UNID table and allocating NoteID)

When a IBM CSLD retrieval process later comes to add the parent note back into the database, the Notes C API call “NSFDbGetNoteInfoByUNID” ( or “NSFNoteOpenByUNID” ) finds the “dummy” entry, making the C API program think the note already exists.   The API program is then able to use “NSFNoteOpen” or “NSFNoteOpenExt” to get a valid note handle for the note and can start working with it.  All appears to work fine, however, after “NSFNoteUpdate” or “NSFNoteUpdateExt” is called for the parent note, although the note content is stored in the database and the header information gets updated, the note is not visible.

The problem has been diagnosed by the Domino development team under SPR:FJAD7WCL92. in a particular customer incident it was addressed from Commonstore side.

Resolving the problem
The problem has been diagnosed by the Domino development team under SPR:FJAD7WCL92. in a particular customer incident it was addressed from Commonstore side.

Workaround 1
In a particular customer incident it was addressed from Commonstore side. The workaround as used by the Commonstore team is based in the fact that to distinguish a Ghost note from a Regular note, the note can be checked for items. If the note contains no items (fields), then its assumed the note is a ghost note.  If it is a ghost note, instead of updating/saving that note, the api code can simply close the existing note handle and use NSFNoteCreate to create a new note, update it with the applicable data and then save it.
As an alternative, the Sequence Number (SN) can be checked, under normal circumstances, when a note is normally created, it will have a sequence number of 1, and increases each time the note is modified. When NSFDbGetNoteInfoByUNID is used to determine whether the note exist in the target domino database, a ghost note would always return a SN of 0. When this situation is found the same repait steps as in the first workaround can be used.
Full note info of a ghost note:
OID 'OF: - ON: - SD:                
00000000:00000000 - SN: 00000000'.                                      
Mod DateTime returned is ''.                             
Note Class returned is '1'.