Have you every looked at a database someone else designed? Or maybe one you designed but haven’t seen for a while? What do those tables mean, and how are they related? What is linked to what, and what field names are present? What do the codes, acronyms, and mnemonics stand for? What VBA scripts are installed? Yikes!

People who’ve coded in BASIC or some other language that allows comments understand the value of having some kind of explanatory text. In Crystal Reports, this explanatory text exists as a Crystal Dictionary. As with other functions, this one has an Expert to guide you. When you’re done creating a dictionary, users can report directly from that and not have to learn about the underlying tables and relationships—often a time-consuming and painful task.

Here are three tips:

1. Create a master dictionary. Chances are you’ll have different categories or clearances of users—each with their own dictionary. By using a master dictionary that you update once when new fields are introduced or some other structural change occurs, you avoid having to add those fields to each dictionary. You simply make copies of the master and delete the links that don’t apply to a given group.
   
2. Verify your dictionary. Crystal Reports provides a tool for checking that the tables and fields are referenced and haven’t changed since the last update.
   
3. Distribute what you need. Don’t forget to include the Crystal Reports file (*.rpt) with the dictionary (*.dc5)! Since these are linked, it’s best to keep the structure the same. If at all possible, store the two in the same directory so when you send them the links don’t change as long as they are kept together.