Brian Leach wrote... >Unlike the A/S type dictionaries, there is no standard way of separating >base and synonym dictionaries using D types, which can lead to dictionary >listing that takes forever to plough through to get to the definitions of >later fields, and makes writing automated routines to build BASIC include >files more complex. > >So the convention they adopted was to use D types for all the 'base' fields >(one D type per field) and make all synonyms into I types of the form: > >I >Base_Field_Name > >That way they could see the file layout more easily. I thought that was >pretty smart.
Here are some things I have seen and used on UniVerse that perhaps applies to UniData as well. Using I types in the way described above seems to move the problem of noise from the D types to the I types area. Also, it incurrs additional reporting overhead as an ITYPE() function is far more expensive than an EXTRACT() function. Other approaches include using custom D types or PHrases. The letters following the D in field 1 of the dictionary defintion are treated as comments, where the first space delimits the Type from the Description. Defining additional D types is easy. One site used DP to indicate the Primary field definition and the plain D types were considered synonyms. The DP types had good descriptions for the field whereas the D types descriptions were typically silent. Use PHrases to create customized D types on the fly for use with reporting. E.g. "F1" 6 lines D 1 10L S "TF1" 2 lines PH F1 FMT "33T" Of course, the PHrase solution only works with the report writer. The nice thing about both of these approaches is that they retain the performance of the EXTRACT(). Best regards, Gyle ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
