Hi,
I have read a lot of the postings here and the Help documentation concerning Profile doc, but am still confused on what makes them tick.
They originate like any other doc from a form with fields and the Menu & Search options unchecked. But what “makes” them that allusive element that is not available to all the normal Notes methods of seeing data like views or dialog boxes.
At what point do they become “profile” docs - i.e. what triggers a simple form to morph into a profile doc?
Are certain flags set to make it a profile doc and to hide it from views? Or does something else happen?
What are some specific ways that profile docs are processed by Notes in comparison to ways Notes processes regular documents?
Can these ‘profile’ flags, settings, and/or characteristics be altered using tools in the Designer?
Is there any in-depth documentation or articles still available on Notes profile docs?
I offered up these questions in hope that the few people who really know about Profile docs would share with us all an in-depth explanation of this commonly used database feature in one of the last threads on this forum.
Thanks very much,
Tim
Subject: Profile Document Make-up
It’s not well documented. It comes down to the fact that at the low level, one set of Notes API calls is used to create and update profile documents, and a different set of Notes API calls is used to create and update regular documents - which are also known as “data notes”.
Note that a form doesn’t “morph into” a profile document any more than it morphs into a regular document. A form is just a design element that is used for presentation purposes. The Notes client uses forms for constructing the UI for both regular and profile documents, but it uses NSFNoteCreate, NSFNoteOpen and NSFNoteUpdate for accessing regular documents and it uses NSFProfileOpen and NSFProfileUpdate for accessing profile documents. The rest is “magic” for all intents and purposes. I.e., the view indexer and the NSFSearch API can’t see any notes that were created via NSFProfileOpen, and NSFProfileOpen can’t find any notes that weren’t created via NSFProfileOpen. The root of that magic is that NSFProfileUpdate adds the noteId of the profile note to one data structure in the NSF file which is optimized for cached access via the profile name and user id, and NSFNoteUpdate adds the noteId of a data note to a different data structure that is optimized for constructing views and searching on summary data.
You can’t simply convert between the two, but you can copy one into the other, in either direction by writing the appropriate code.
Subject: See my main response.
No message.
Subject: So, that’s how they did it …
Rich,
Thanks very much for this well worded explanation on Profile documents. It definitely takes out a lot of the mystery surrounding the Profile doc. I have always enjoyed reading and greatly benefited from answers you have posted on this forum.
Regards,
Tim