Its been a while since I wrote a good performance tip. This one is a favorite since it affects the most important performance of all -- what the user actually feels.

We have a busy database that resides on a server. It isn't locally replicated. It uses about a dozen keyword lookups as part of the primary form. Forms are opened and closed routinely. Its a helpdesk application in this case so people are forever going in and out of documents. Each lookup gets performed each time a document is opened or switched to edit mode -- the lookups fill in all the drop down lists. That makes opening documents slow.

Here's what I did.

First, I wrote an agent that periodically performs those lookups and stores the results on a profile document. The profile document gets one multi-value field for each of the keyword lookups. You can get fancy, and trigger this only on keyword document changes or whatever -- it wasn't really important in this case.

Next, I added code to the database script, so that whenever a user first opens the database, that profile document is retrieved and its values are copied to a database on the user's local machine. What database did I use? Why their personal address book. I store the values on a document, and give the document the form and type name "Account" -- so it ends up being in the Advanced \ Accounts view in their personal nab. I give the AccountName field a name that means something, so I can use it for lookup (SuperHelpDeskApp in our example).

Result?

When the user opens or edits one of these forms now, the lookup still happens but it happens to a LOCAL file and their local workstation caches the values quite nicely. It makes a huge impact for users across wide area networks, dialup, or other high latency environments. No local nab design changes where needed, and the field size is fine -- which could be an issue if you just try to use environment variables.