This section describes the various Schema options that are available.
Comments may be placed anywhere on a line after a pound sign (``
You can begin lines with a ``
#'' to provide block comments or
place the ``
#'' at the end of each line to document lines separately.
Qddb ignores any text following the ``
See figure 11.5 for a sample schema with comments.
The verbosename keyword provides an option for you to specify a more verbose name for your attribute. In particular, the verbosename value is used by nxqddb to determine the label that appears to the left of the entry on the nxqddb window. For example, consider the schema shown in figure 11.3, and its accompanying nxqddb window in figure 11.4. In this schema, we created verbosenames for each attribute. Remember, attribute names cannot have spaces. Hence, we use the verbosename option to create labels that have spaces. We also added colons to the end of the verbosename to help serve as a delimiter to the entry field.
name verbosename "Full Name: "
number verbosename "Phone Number: "
ssn verbosename "Social Security Number: "
Figure 11.3: Schema with verbosenames
Figure 11.4: nxqddb window using a schema with verbosenames
The default type for an attribute is string. You can change an
attribute's type by keying the phrase ``
next to an attribute. Figure 11.5 provides example
schemas that illustrate how to define the various types.
# Schema to illustrate "types''
Name # this field defaults to type string
Birthday type date # date field
Cash type real format "%6.2f" # currency field, 6 digits with 2 to right of decimal
Number type integer # define an integer field (accepts positive or negative integers)
Figure 11.5: Schema illustrating how to define the various types of attributes
So, what does it mean to declare something as string versus, say an integer? If you declare an attribute as an integer, nxqddb will only allow you to type numeric characters in the entry field. Meaning, nxqddb restricts your input to a valid integer. Similar validation is performed on real, and date attributes.
The format keyword tells nxqddb how to print/display attributes that are defined as (1) type date, (2) type integer and (3) type real. If you don't have one of the above three types of attributes, then nxqddb will just ignore the format qualifier. The format keyword has no impact on how you enter the data; remember, the validation is handled based on the type.
For integers, you may specify any of the standard ``non-``C'' programmers, this format allows you to specify things like
padding, zero-fill, etc. The default format is ``To learn more about how to format integers,
reference your online man page by entering the following at your command prompt:
man 3 printf Common integer formats are illustrated in
Table 11.1: Examples of formatting integer types
Similarly to integers, you can specify the format for real numbers. Users commonly specify the precision of the real number using the ``
Table 11.2: Examples of formatting real types
The default format for real types is ``
For formatting date attributes, you may specify almost any combination of the ones illustrated in figure 11.3. For further details on the date format, see the man pages for strftime(3), asctime(3), and mktime(3). The default format for dates is either ``installation of Qddb was configured
Table 11.3: Date format options
You may enter dates in almost any format, except that ``nn/nn/nn'' is interpreted as ``%m/%d/%y''. You can override this interpretation when you install Qddb so that such input will be interpreted ``%d/%m/%y''. Some combinations of date format, such as ``%d;%b;%y'', are not currently recognized by Qddb. If you provide a date format that Qddb cannot interpret, you will see an error when entering dates. Most common formats are supported.
You may also enter dates relative to some date(see table 11.4).
Table 11.4: Keywords available for date attributes
You may also use the day-of-week keywords
Month names are also fine. For example,
the following are all valid input to a date attribute:
The input ``
next tuesday'' does not mean this coming (or current)
the one after. The keyword ``
tuesday'' means the coming (or current)
Aliases provide a way to provide a simple (often much shorter) name
to an attribute. The use of aliases are especially helpful if you
are programming with Qtcl and you have many levels of nested structured attributes.
Also, using aliases, you can save some typing whenever you create your
custom Email, letters and postcards through the nxqddb report generator.
The alias syntax is simple, for example to alias a ``SocialSecurityNumber'' field,
you might enter
SocialSecurityNumber alias ssn.
You can tell nxqddb to prepopulate an entry with a default value when you are in ``Add Mode''. For example, consider a ``City'' attribute. If most of your entries live in say ``Cincinnati'', you could specify a default value of ``Cincinnati'' and this value would appear in the nxqddb window whenever you go to ``Add Mode''.
Many users find it convenient to prepopulate ZipCode attributes with a partial default
value. For example, suppose you happen to have say 95of the five zip codes 41016, 41042, 41017, 41011 and 41015. In this case, you
would create the ZipCode schema like so:
ZipCode defaultvalues ``410''
The exclude option tells Qddb to exclude indexing on the attribute. If you specify the exclude option on a field, you will not be able to perform searching on the field. Typically, you want to use the exclude option only on fields that you know will never be used as search criteria fields. For example, fields that you may want to exclude from searching might be: sales tax, subtotals, or any other field that would yield meaningless search results.
Separators tell nxqddb how your data values are to be parsed into words during a word search. If you don't specify the key word ``separators'', then Qddb abides by the following rules when parsing words:
The default separators are shown below:
Suppose you have data that contains the delimiters: ``:'' and ``/''. For example, say you have a string like ``foo:bar/whatever this is''. To handle this scenario, you would set the separators to ``:/'' as shown in figure 11.6
# Schema containing separators
MyField separators ":/"
Figure 11.6: Schema to illustrate the use of separators