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

The nice thing about @Unique is that it's unique -- at least for a given user on a given workstation.  The value contains a user initials part and a date/time based part, and the client keeps track of the last value assigned. If you call the function twice close together, and will bump up the date/time part, if needed, to give you a different value each time. The date/time part consists of six alphanumeric characters constituting a base-32 number.  But wait (you might think), 26 letters + 10 numerals = 36, not 32. The reason for the discrepancy is that 0 and 1, O and I are excluded to avoid ambiguity when you see the number written down.

There are a few problems with using @Unique as an identifier, though:

  • The alphanumeric identifier is non-optimal for reading over the phone, because many letters have similar names.  Most end-users (and phone staff) have not memorized the word-codes (alpha, bravo, charlie) that military and firefighters use on the radio.
  • The user initials aren't necessarily unique to each user, causing potential duplication.
  • The date-based part comes at the end, which is handy if you want to sort all a user's documents together but less useful if you prefer documents to sort based on when created.  Not that you couldn't sort documents either way based on other fields, it's just a matter of what do you want the first part of your identifier to represent.

Here's a formula to address these issues while still maintaining the useful aspect of @Unique (not giving dups to a particular user):

_initials := @DbLookup(""; ""; "(UserPrefixes)"; @V3UserName; 2; [FailSilent])[1];
_tmp := @Unique;

_suffix := @If(@IsError(_initials); @Left(_tmp; "-"); _initials = ""; @Left(_tmp; "-"); _initials);

_from := "2":"3":"4":"5":"6":"7":"8":"9":"A":"B":"C":"D":"E":"F":"G":"H":"J":"K":"L":"M":"N":"P":"Q":"R":"S":"T":"U":"V":"W":"X":"Y":"Z";

_i := -1;

_to := @Transform(_from; "x"; @Text(_i := _i + 1) + ",");

_digits := @ToNumber(@Explode(@ReplaceSubstring(@Right(_tmp; "-");_from; _to); ","));

_cur := _digits[1];

@For(_k := 2; _k <= @Elements(_digits); _k := _k + 1; _cur := _cur * 32 + _digits[_k]);

@Text(_cur) + "-" + _suffix

This assumes you have a view of "user prefix" documents with a unique code for each user, set up in advance. If no matching document is found, this formula uses the initials that @Unique provides automatically, but you could instead opt to error out in that case, to make extra sure the ID is unique.

It's up to you whether the user codes in your lookup view are letters or numbers, but I like letters.  Unless your application is very high-volume, the chances of duplicate date/time parts are small.  So, your call center staff could ask for the "number part" of the ID (9 digits), and if they find they have more than one match, ask for the letters after the dash (or just see which of the matching records has the customer's name on it).

Andre Guirard | 7 October 2008 11:28:56 AM ET | Home, Plymouth, MN, USA | Comments (10)

Search this blog 


    About IBM Privacy Contact