The year can be expressed as a 4-digit number or as a 1- or 2- digit number representing the year in the current century. For example, “92” means 1993, “44” is illegal (1944 is before 1970), and “1” is illegal now, but anytime after the beginning of the next century will mean “2001.”

The month can be either a number from 1 to 12 or a month name or a 3-letter month abbreviation. Case is not considered.

The day of the month is expressed as a number from 1 to 31.

The day of the week can be included in date input, but is not used to interpret the date. In fact, the day of the week is ignored in date input. The day of the week can be a day of the week name or a 3-letter abbreviation.

The syntax for specifying the time of day is:

HH [ :MM [ :SS ] ] [ am_or_pm ] [ time zone ]

The minute and second are optional, as are the AM or PM designator and the time zone. If neither AM nor PM is included in the time of day, the hour is interpreted on a 24-hour basis. If a time zone is not specified, the current local time zone is used. The time zone can be either a 3-letter time zone name or a 4-digit offset from GMT (now known as Coordinated Universal Time or UTC).

The recognized time zones are shown in Table 6-2.

You can specify a date in relative terms by adding or subtracting a time interval from a given base date. The adjustment always follows the base date and is specified as follows:

+ | - [ [ [ DD: ] HH: ] MM: ] SS

The current date and time can be referenced in date input. Tracker supports these current date and time reference forms:

You can use the application class name as the name of the application defaults file. Since rtsquery's class name is Rtsquery, its application defaults file is in /usr/lib/X11/app-defaults/Rtsquery.

You can also use all of these names to set resource values. To set a resource, you name:

If the resource is used only by one widget, or if you want to set it for all widgets that use it, you can omit the widget name; all widgets using that resource will pick up the set value.

Since there are many widgets in an application, several widgets often end up with the same name. To clarify which one you want, you can specify the widget hierarchy that contains the particular widget. Widgets are arranged inside one another, like a set of bowls in graduated sizes, and this structure is directly reflected in the PDL text that you find in the application file. A large widget makes up each whole window (called the view) and contains all of the other widgets. Arranged inside and completely filling the view are several display widgets, which create the sashes that allow you to change their height. Inside each display widget are other widgets: control-bars, rows, and so on. If you look at your application and the application file side by side, you should have no trouble matching the features and identifying the names that the system designer has assigned.

To set a resource for some widgets of a given kind, but not for others of the same kind, you need to specify the names of some of the containing widgets, as well as the name of the widget you actually wish to control. This is done with a limited sort of wild-carding. For example, to exactly specify a particular widget, you can specify the application name and all the widget names down to the end, as in:

app.widgOne.widgTwo.widgThree.resource: value

Or, more commonly, you can leave out some or all of the widget names, replacing them with an asterisk:

app*widgThree.resource: value

Since an application defaults file is only used by the “right” applications, you don't need to specify even the application name. Most resources are specified like this:

*widgThree.resource: value

You can use this simple form in your ~/.Xdefaults file too, as long as you are sure no other applications will use the value. But it is generally safer to include the application name.

You can also set resources for all data of a particular type, which includes data in lists that do not have widgets. To do this, you must concatenate the type name (from the PDL fields section) and the resource itself:

Rtsquery*file_fileDisplayStyle: \
   FileDisplayVobStorage

Resources that you set in your own resource file usually take precedence over settings in the application defaults file. However, precedence is also based upon exactly how the resource is specified. To override a setting from the application defaults file, follow these steps:

Where appropriate, the description will mention which kinds of widgets use this resource. Where this is not mentioned, the resources control the behavior of the entire application.

By default, if the file ~/.<appname>-query (or the file specified by the resource *startupQueryFileName) is found upon startup, the query stored there (by the application's Query menu “Save As Default” item) is executed immediately so that the application comes up displaying its results. Setting this resource to False prevents this.

All widgets that display data from the database obey this resource. If invalid data is entered into such a widget during an edit and this resource is set to true, a highlight is drawn around the field and a dialog is popped up to explain the error.

All widgets that display data from the database obey this resource. If invalid data is entered into such a widget during a query and this resource is set to true, a highlight is drawn around the field and a dialog is popped up to explain the error.

All widgets that display data of type file obey this resource. File names that name a file in a CASEVision/ClearCase Versioned Object Base (VOB) can be displayed in two formats. The default format, FileDisplayVobMount, is a standard ClearCase version-extended pathname, which includes the file system path to the file and the version information, for example:

/vobs/CASE/usr/src/foo.c@@/main/37

This format is familiar to most users. If displayed on a system where the VOB is mounted in another location, it will show the new location. If displayed on a system without the VOB mounted, or even without ClearCase installed, the string displayed to the last person who edited the file will be used.

The other display format, FileDisplayVobStorage, shows where the VOB is actually located, for example:

(vobhost:/storage/CASE)/usr/src/foo.c@@/main/37

This presentation can be useful to administrators investigating user complaints that the first form names a file that doesn't exist.

This resource controls the number of entities retrieved from the database each time the query results pane is updated. Setting this resource higher than the default may improve the scrolling performance of query results. Setting it too high may increase the delay before the first query results are displayed.

This resource applies to the layout of the field value options in the GUI. If the number of options is 25 (the default) or fewer, they appear on a rollover submenu reached from the “Values” menu item on the field menu. If there are more than 25 options, Tracker displays them in a scrolling list. You can set the default at which the scrolling list appears to any number you choose.

This setting means that you must click the mouse button in a field before you can enter data. Setting it to pointer means that you can type into whichever field is under the mouse pointer.

This setting means that you can move from one input field to another using <Ctrl Tab> (move forward) and <Shift Tab> (move backward). <Tab> also moves you forward from single line fields, but in multiline fields it merely inserts a tab. Setting it to False means you must move the mouse pointer to another field to enter data in it.

A scheme is a set of coordinated colors, fonts, and other properties. A number of schemes are provided in the CASEVision environment (installed along with Tracker). You select which scheme your CASEVision applications use by setting this resource. The default scheme, Lascaux, matches many other IRIX tools. You can preview the other schemes with cvscheme, which is also a part of CASEVision. (For more information, see the cvscheme man page or the CASEVision Environment Guide.)

Every scheme provides two entire sets of fonts. By default, Tracker applications use the set of smaller fonts because Tracker windows tend to be large and cluttered with the larger fonts. If you prefer the bigger fonts, set this resource to False.

When importing data, it's best to explicitly type the data. This is an optional DML feature because most data values are automatically recognized as belonging to a particular type; however, explicit typing, can clear up ambiguities, such as the difference between short-text and long-text values. More importantly, while you're importing data from another system, some data might not match expectations—either Tracker's expectations, or the expectations you had when you wrote the import script. Explicit typing helps to ensure that such surprises don't slip past you into the Tracker database. Even if you take the approach recommended above, you'll at least want to know that there is a problem.

Explicit typing is accomplished by enclosing the data item in single quotes (apostrophes), and preceding it with the type name, that is, the name used to declare the field in the PDL file. Both long-text and short-text string types already require the surrounding quotes; you need to add only the type-name.

Your first attempt to import a large database may not be flawless, but you should be able to import a majority of your data easily, and then focus on the few reports with difficulties. You don't want to discard the reports you've inserted correctly, yet you don't want to turn one real report into two records in the database.

You should focus your attention on getting the import script right, rather than on remembering exactly which reports worked and which failed. The DML includes a very useful construct for this sort of situation, the insert ... where statement (this is not in standard SQL).

A normal insert statement creates a new record unconditionally, which is fine for the first time, but not so good when you're doing updates. The update ... where statement updates records already in the database, but does nothing if the record described in the where clause doesn't already exist. If only these two statements were available, you would be required to know the exact state of your database at all times and to adjust your import process accordingly. This is inconvenient during an import.

The insert ... where statement solves the problem. It's a synthesis of the insert statement and the update statement: if one or more records can be found that match the where clause, then it behaves as an update statement, changing the existing record(s) and creating no new ones. If, however, no such record exists, insert ... where behaves as an insert statement, creating one new record with all the values included in the statement.

When you're importing a block of data using your import script, you'll probably encounter a few reports that cause problems in some way. Often, you can make a minor enhancement to your import script, and re-import the same block of reports. If you've written your script to use insert ... where, the reports that succeeded before will merely update themselves to the same values; the reports that failed before will be inserted now.

To use insert ... where effectively, you'll need to know the field(s) of the incoming reports that uniquely identify them. (Your Tracker database assigns an $ENTITY_ID uniquely to each report, but you won't know that value for the incoming data, so it can't be used here.) Your old system may already have a sequence number or something similar. If not, you may be able to create a unique key using several fields. For example, if your old system records who originally submits a given report, and also records the time of submission fairly precisely, the submitter plus submission time will probably be unique because no single person can submit more than one report per second.

Some fields values may cover more than one line. For example, nearly every system has at least one field where the problem is described, which is usually more than a single line. Similarly, lists of items can span several lines. The example presented here uses nawk(1) to translate the text, however, and nawk is primarily line-oriented. A problem arises: you'll be writing this nawk script to recognize certain lines that identify fields and their values in the input, but you don't want to be misled by similar text buried within a body of text.

The solution used here is to notice when a multiline item begins; its beginning is easily recognized in the same way any other field value is recognized. A flag is set, indicating that the parsing is currently somewhere within a multiline item. A few rules concerned with noticing the end of such an item appear at the top of the script (so that they're considered before the general rules); these rules match only while the flag is set. These rules are principally responsible for recognizing the end of the multiline data.

The string data itself may contain quotes besides the quotes used to delimit it. The DML requires that such a quote has a backslash in front of it, like this: (\'). This in turn makes backslashes special: they, too, require backslashes in front of them.

If you have so many defect reports to import that you're considering writing a script to do it, you can probably determine how long this script will take to run. You can improve the performance of your script by making it surround groups of insertions in transactions; otherwise, each individual insertion will be a transaction by itself, which is time-consuming for the server. The exact number of reports you include in a given transaction isn't too critical in this context; grouping at least ten together is advantageous, but above that the rate of gain begins to fall off. If you make the transactions too large (say, hundreds of reports), things will slow down because the server grows too large (storing the pending transaction) and begins to page unduly. Twenty-five reports per transaction seemed to be a good compromise.