Global profile documents
Global profile documents contain settings that are applied across an entire database or application. The trick to creating a global profile form is that you want to ensure there is only one document ever created with the form. In our example we will create a global profile document to store different language settings for the days of the week and month names.

If you are following along from my last article, open the database that contains the popup calendar form and create a new form named "CalPro" (calendar profile). Next, create a computed text field named "docid", the formula for this field should be: @Text(@DocumentUniqueID). We will use the unique id of the document to ensure we only allow one document with this form per database.

Beside docid, create a computed text field named "SaveOptions". SaveOptions is a reserved Domino field name that controls whether the field contents in an edited form will actually be saved when the save command is issued. If this field is set to "0" then no save occurs and no new document will be created. The formula for this field should be:

This formula consists of one @If statement nested inside another. The first @If statement checks to see if it can do a lookup in the cal_profile view (which we will create in a minute) for the first document and tries to retrieve its unique document id. If this lookup is an error, then no documents exist with this form so the SaveOptions field gets set to "1" which means changes will be saved.

On the other hand, if the lookup is a success, that means a document already exists with this form. The second @If statement retrieves that document's unique id, and compares it to this document's unique id. If they match then we are editing the right document and the SaveOptions field becomes "1". If they don't match, the user is trying to create a second calendar profile document, so we set SaveOptions to "0" to prevent the user from saving.

Next, create a radio button field named "SelLang". This will control which of the languages will be the current active language. The choices for this field should be "Lang1", "Lang2", etc., depending on how many languages you want to provide. My next article will make this field obsolete, as we will create individual profile documents for each user, allowing each user to select their own preferred language.

We now need a series of fields to hold information on the names of the days and months in different languages. First, create an editable text field named "Lang1_Name", and then a table to hold fields for the days of the week (Lang1_SU for Sunday, etc.) and for the month names (Lang1_Jan for January, etc.) as depicted in Figure A.