To store the configuration of Notes applications, there are to obvious
possibilities and a third, not so obvious one, combining the benefits of
the other alternatives, in two variants:
First alternative: profile documents
For this method you create one or more
forms, but no views. To create configuration documents you use @EditProfileDocument
instead of @Compose. To access stored values use @GetProfileField or NotesDatabase.GetProfileDocument.
The main advantage of this approach
is performance. Its very efficient to get the profile documents and they
are cached in the memory of each client.
This is also this method's biggest disadvantage.
When a profile documents gets change by another user, the current user
sees the old values until closing and reopening the Notes application.
Another disadvantage is its reliability: Sometimes the profile document
gets empty (only in older versions of Notes?). This can happen - for example
- if there is a replica of the database, where - for whatever reason -
the profile document does not exist or is not visible to the current user.
Then a new and empty one gets created (even if the user only wants to read
this document or one of its fields). The next time, the database get replicated,
this profile document is newer then the original one and therefore replaces
it.
Second alternative: normal documents
and views
In this case you create one or more
forms and at least one view. You create the configuration documents using
@Compost or with View - Create. To access the stored values, you use @DbColumn,
@DbLookup, NotesView.GetAllDocumentsByKey or NotesView.GetDocumentByKey.
Advantages: The documents are more "visible".
Changes are in effect immediately (except when using [Cache] in the @ formulas)
and this solution is more reliable.
But you have to pay for this advantages:
The performance is really bad (in comparison), since the necessary view
look-ups take quite some time.
Third alternative: a combination
Lets try to combine the advantages of
both alternatives without their disadvantages. There are at least two approaches:
Variant 1: data duplication
As in the second alternative, you create
forms and views and you also create "normal" documents to store
the configuration in a reliable manner. But additionally every time the
"normal" document is stored (e. g. in the PostSave event), you
create or update a profile document with the same values. To access the
data, you use the profile document (@GetProfileField and NotesDatabase.GetProfileDocument).
When the profile document gets "lost" somehow, you - or a user
with the necessary rights - just has to re-save the "normal"
configuration document in order to recreate the profile document. But you
have to actively interact with the application and the disadvantage with
the cached values remains.
Variant 2: Pointer to "normal"
documents
Here, too, you use forms, views and
"normal" documents to reliably store the configuration information.
But differently from the former solution, you don't store the whole data
in a profile document, but only the UNID (@DocumentUniqueID or NotesDocument.UniversalID)
of the "normal" document. To access the values, you use a @GetProfileField
or NotesDatabase.GetProfileDocument to get the UNID of the configuration
document first, and then use it with @GetDocField or NotesDatabase.GetDocumentByUNID
to get the document or field value itself.
This variant is nearly as fast as the
first alternative, since no view look-up is necessary. But the configuration
information is stored safer and more reliable in "normal" documents.
Further on, changes of configuration values are taken into account immediately,
because only the UNID is cached.
If the profile document gets "lost"
somehow, you can simply add some code to do a view look-up and store the
UNID in a new profile document for later use. This can occur automatically,
thus you don't need to manually intervene.
