Cache strategies with @Dblookup, and more (Page 2)

Search DominoPower's 11,441 Lotus-related article archive

Home
EasyPrint
News details

Articles-only

Twitter Feed

Cache strategies with @Dblookup, and more (continued)

Some more tips
But what if you then used the same look-up two or three times in other fields on the form? What you'd like to do there is have the first look-up forced to go back to the server, but you'd be happy for the subsequent choices to use the same value list. Indeed, you'd want to do that, because, should the underlying data happened to change as the form opened, the results would be strange and hard to explain why some field choices were different to others.

That's where the ReCache parameter comes in. That was new in Release 6, but I have to say I've only used it a time or two, and I've never seen any other application use it. NoCache, when used, tells the look-up to bypass any cached values and go to the server for the data. However, it does not refresh the cache, so if the data has changed, a subsequent look-up without NoCache will get the originally cached dataset, and that would be again be a strange result. What ReCache does is do the server look-up, just as NoCache does, but also refreshes the look-up cache ready for subsequent look-ups to get the latest data without the overhead of a server trip.

What that means is that if you have a form that has two @DBlookups or @DBColumns on it that return the same value list, specify the first one with ReCache, and the second (and all subsequent ones) without the cache parameter at all. The same advice goes for complex formula actions or agents that repeat a look-up.

New parameters in @DBLookup
While we're discussing look-ups, are you aware of new parameters that were added to @DBlookup back in release 6? Again, these are things I've been aware of, but have not seen them used. These are keyword values that are listed as an optional extra parameter after the field or column number parameter. You can specify more than one: separate them as a list with a colon.

[FAILSILENT] tells @DBlookup to return an empty string instead of @error if the @DBLookup fails, which can simplify your coding no end:

You commonly see code:


lookedupvalue:= @if(@iserror(@DBLookup(....);"";@DBLookup(.....));

This does the @DBlookup twice, once to see if it will work, and the second to return a value. By the way, if you do this, don't use NoCache on the second one -- not just because it's wasteful, but because it may cause the @DBLookup to return a different value, and that different value might be @error!

Instead, you can merely code:


Lookupvalue:=@DBLookup(........;[FAILSILENT]);

This will return either a looked up value, or "".

The other new parameters are [PARTIALMATCH], which enables a partial match result to be returned. This is similar to the use of NotesView.GetDocumentByKey(keyvalue, False). As with GetDocumentByKey, you need to be careful with this one, because partial matches are not often what you'd want to retrieve.

[RETURNDOCUMENTUNIQUEID] returns the @DocumentUniqueID value of the retrieved document, rather than any field or column values. That would then enable you to retrieve a number of fields using @GetDocField, rather than repeat the @DBlookup each time:


tempUNID:= @DBLookup(.....;[RETURNDOCUMENTUNIQUEID];

field1:=@GetDocField(tempUNID;"Field1");

field2:=@GetDocField(tempUNID;"Field2");

It's worth noting that, unlike NotesDatabase.GetDocumentByUNID where you get 4091 error if the UNID value isn't a valid UNID value, or the target document can't be found, @GetDocField returns "" (strictly, it returns null) if the document can't be found.

Jennifer Regnault is a Senior Consultant with Casahl Technology. Casahl is a Lotus Premium Business Partner that provides leading software solutions for D2D and B2B integration challenges. She can be reached online at jregnault@yahoo.com.