Coding @DBLookup - taking another look.
As developers become comfortable with
a development environment they develop habits of coding that tend to continue
even as the development environment is enhanced to make coding easier.
This occurs for several reasons: old habits die hard; code library reuse;
copy & paste from other applications. For these reasons, you like I
may not remember that error handling for @DBLookup was made easier in Notes/Domino
6.
Recently I was hand coding a formula
that included @DBLookup and had a senior moment which sent me to the Designer
Help database. There I noticed an additional keyword parameter. The one
that caught my eye and was used immediately was [FAILSILENT]. This keyword
allows @DBLookup to return a null string should the function fail for any
reason.
Prior to using this parameter my standard
error handling for @DBLookup looked like this:
FieldName:="fd_Products";
ViewName:="va_LUProductLine";
Key:=fd_ProductLine;
Retval:=@Explode(@If(fd_kw_Products!="";fd_kw_Products;@DbLookup("";"";ViewName;Key;FieldName));";")
@if(@Iserror(Retval);"";Retval);
No I can eliminate the last line of
the formula by adding the [FAILSILENT] keyword like this:
FieldName:="fd_Products";
ViewName:="va_LUProductLine";
Key:=fd_ProductLine;
@Explode(@If(fd_kw_Products!="";fd_kw_Products;@DbLookup("";"";ViewName;Key;FieldName;[FailSilent]));";")
Two other keywords are available: [PARTIALMATCH]
and [RETURNDOCUMENTUNIQUEID]. The first allows for returning non-exact
matches. The return values need only match the first few characters in
the lookup key. The second keyword, [RETURNDOCUMENTUNIQUEID], returns the
UNID of the document(s) found instead of a field or column value.
So now I've changed my coding habit
to include [FAILSILENT]. I hope when the occassion arises I will remember
the other two keywords and not use old habits to get the same results.
-