Skip to main content
    Country/region select      Terms of use
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

I've been doing some experimenting to determine best practice recommendations about profile documents. They're problematic for use in web apps, granted, because their cache on the web server is very long-lived. For client applications, however, I don't see any reason to avoid them, and from a performance standpoint they have much to offer as an alternative to looking up configuration information using @DbLookup or @DbColumn.

The main problem you need to avoid in the client, is the creation of blank, duplicate profile documents when someone uses a replica that's not fully initialized (i.e. has not yet replicated the profile document). However, this is not hard to do.

First, @GetProfileField will never create a profile document. You can use the function on forms and so forth without worrying about creating bogus profile documents if the profile hadn't been replicated yet to a new replica. @SetProfileField will create a profile if it doesn't exist.

Profile documents are also unaffected by replication formulas. I'm sure this hasn't always been the case, but not sure when it changed. Again, with this change, there's less chance of the profile getting zeroed out by someone trying to use it in a local replica.

We also have ways in LotusScript now, to retrieve a profile document without creating it. Instead of db.GetProfileDocument(x) you can now do, for instance:

Set docProfile db.GetProfileDocCollection("MasterProfile").GetFirstDocument()

And then, of course, you have to check whether docProfile "Is Nothing" before you try to use it, but really you should be doing that anyway.

As for keeping track of your profile documents, some time back I posted a tool to view and control all the profile documents in an application.

To let someone edit the profile, you would want to do it in a way that can't result in someone creating a duplicate profile -- at least not without a fair warning. So you wouldn't just use @Command([EditProfile];...). Instead, you could use an action button or agent with code such as the following:

Option Public
Option Declare ' always use Option Declare
%INCLUDE "lsconst"

Const WINDOWTITLE = "Application Setup"
Const PROFILENAME = "MasterProfile"

Sub Initialize
     Dim session As New NotesSession
     Dim wksp As NotesUIWorkspace
     Dim db As NotesDatabase
     Set db = session.CurrentDatabase
     Dim docProfile As NotesDocument
     Set docProfile = db.GetProfileDocCollection(PROFILENAME).GetFirstDocument()
     If docProfile Is Nothing Then
             If db.CurrentAccessLevel < 6 Then
                     Msgbox "Only the database manager may create the setup document.", _
                     MB_ICONSTOP, "Application Setup"
                     Exit Sub
                     Dim result%
                     result = Msgbox({Warning! Setup document does not exist. Do you want to create one?

If one already exists in another replica of this application, it will cause problems.}, _
                     If result = IDNO Then
                             Exit Sub
                     End If
             End If
     End If
     wksp.EditProfile PROFILENAME
End Sub

Come to think of it, I guess you could do this using a formula if you used @GetProfileField first to check whether the thing existed. To check whether a profile document exists in formula language:

@GetProfileField("profilename"; "$Name") != ""

So to integrate this into a "Edit Profile" action:

PROFILENAME := "MasterProfile";
@If(@GetProfileField(PROFILENAME; "$Name") != "";

       "profile exists - continue";

@UserAccess(@DbName; [AccessLevel]) = "6";

       @If(@Prompt([YesNo]; "Application Setup"; "WARNING! You are about to create a new setup document, which will be a problem if there's already a setup document in another replica which hasn't been replicated to here yet. Do you want to proceed?");





               @Prompt([Ok]; "Application Setup"; "Sorry; only a database manager can create a setup document.")



@Command([EditProfile]; PROFILENAME)

So, if we have some holdouts who are still not wanting to use profile documents in their Notes client applications, please comment -- why not?

Andre Guirard | 25 March 2009 06:54:04 PM ET | | Comments (12)


1) Numeric Sequential Number
Edson | 4/15/2009 10:19:10 AM

The only situation I avoid using a profile document is when we need to provide code-numbers for new documents in the application. If we store the "last number used" in a profile document, the risk of generating documents with dupplicate numbers is very high. I haven't read it anywhere, but practice showed that profile documents do not follow the save controls (from method) that other documents do.

Thank you.

2) Access rights
Theo Heselmans | 4/15/2009 10:29:04 AM

I use profile documents a lot. Usually 1 DB profile for defaults, settings,..., and 1 for each user.

Especially the not fully initiated replica has been bugging me for years, but we can prevent it now. My only issue is that it happens sometimes that a user can no longer edit his/her own profile doc. It becomes read only, resulting in e.g.dialogboxes, based on the user's profile, shows up, but all fields are disabled. Only solution: delete the profile doc, and have the user create a new one. I've never found the real reason for this behavior, as it is sporadic. I now try to add a docauthors field sometimes with a userroles [Profile], which I assign to all users. This usually helps.

But regardless, I love profile docs.

3) So tell me again why you’re not using profile documents?
Andre Guirard | 4/15/2009 1:04:03 PM

@Edson, I definitely agree profile documents should not be used for sequential number generation or for storing any other data that changes frequently. See

4) Corruption
Benoit Dubuc | 4/15/2009 1:29:58 PM

Well, I haven't used them a lot lately, because I,m doing more web development than client development, but back in R5, we had an application with some profile docs that contained lots of data (keywords, translations, ...). These profile docs got corrupted often and it became a real PITA, so we converted to standard docs.

I guess (hope) that things are better now, but I still like to avoid them if possible. Probably because it is now a habit more than profile docs not being useful...

5) Not knowing when new values are valid
Gerald Mengisen | 4/15/2009 2:06:03 PM

The caching - the advantage of the profile documents - turns into a disadvantage when you have no clue when the updated values take effect. So I'd rather use a config doc where I can be sure how it behaves.

And BTW: Try copy / paste for a profile doc...

6) So tell me again why you’re not using profile documents?
Andre Guirard | 4/15/2009 4:19:49 PM

@Gerald, so you would use profile documents if you could be assured that all users would see the new values within, say, 90 minutes of the document being updated in their replica?

I'm considering recommending having the profile cache expire after a (perhaps configurable) period of time.

7) Mix of Java and LotusScript/@-formulas
John Dalsgaard | 4/15/2009 4:47:54 PM

I use profile documents a lot - especially for configurations. However, I always create a real document that is shadowed to a profile document when closed. This way I get the easy copy/paste (or standard configuration when creating a database from a template) AND the performance from the profile documents.

However, I have had problems when I use Java and LotusScript/@-formulas in a mix. If I update a profile document from Java then I am not able to see the updates from LotusScript or @-formulas....

8) So tell me again why you’re not using profile documents?
Andre Guirard | 4/16/2009 1:37:13 PM

So are you guys suggesting that you can't copy from a field on a profile document and paste into a field on another profile document? Or are you talking about copy/pasting the whole document, like from a view?

What if I just added to the profile management tool a button to "copy selected to..." and let you either browse to select a database, or paste a database link of the db into which you want to duplicate the profile?

Copy from one profile management screen and paste to another, via actions, is also an option, but not via Ctrl+C/Ctrl+V -- or at least I don't see how.

BTW if you want to keep profiles in sync it can be easily done with a scheduled agent.

9) Not sure
Gerald Mengisen | 4/16/2009 2:52:02 PM


When you update a setting for an application, it would not look very good to tell the user "thank you - and it can take up to 90 minutes for your changes to take effect." That looks so backwards these days.

What I would need is immediate update of the cache for the current replica. We also have to distinguish two cases:

- global profile document: immediate availability of updates globally

- profile document per user: sufficient if code running in the user's context sees the update in the current replica right away.

10) Profile documents disappear in an application
Patrick Kwinten | 4/17/2009 4:51:56 AM

Hej Andre, I have an application where certain profile documents seem to disappear all the time.

What can be the cause and more important how can I prevent this?

There is no function available for end-users to delete the profile document...

11) double linkage
Lars Berntrop-Bos | 4/18/2009 9:07:02 AM

An interesting use I have read somewhere (original author please forgive my forgetfulness)

Use a profile doc for unique ID's, and then you can at least quickly retrieve the doc without a view lookup.

12) disappearing profiles
Andre Guirard | 4/19/2009 2:32:29 PM

@Patrick, this can happen when someone uses a function that creates a profile document if one doesn't already exist, in a replica that does not (yet) have a replicated copy of the profile. The new profile is blank, of course, and it replicates out to other servers that _do_ have the old profile. When you request the profile document, you can get the blank one returned, making it appear that the original one has disappeared. Probably it's still there, though, and you can find it using NotesPeek or the profile document management tool described above.

As described in this blog entry, careful design of the application can prevent this problem.

13) Too many user profiles??
Randy Parsons | 6/4/2010 2:37:21 PM


I have been using Profiles for years and yes learned the hard way to never use them for sequential numbering. However, if I understand correctly, do ALL profiles get cached into memory or just ones that are not user specific? If this is the case, would adding a Readers field with only administrators and the specific user solve all these being cached and of course speeding up the start up time. I have over 1000 user profiles in this one application and am trying to optimize as much as possible.

 Add a Comment
Comment:  (No HTML - Links will be converted if prefixed http://)
Remember Me?     Cancel

Search this blog 


    About IBM Privacy Contact