Data entry fields – code table and data dictionary fields

RefTracker provides more than 200 standard fields, and the ability to add an unlimited number of additional fields, that can be used to collect data in Request forms.

The data entry fields are listed in the RefTracker Dictionary – question, client, ILL, and bibliographic tables.

Only the fields that have been enabled in your Code tables and Data dictionary are available for use in Request forms.

Within the question, client, bibliographic and ILL tables, data entry fields can be of the format:

data entry box (a single line data entry field allowing up to 2000 characters).
data entry area (a multi-line data entry field allowing up to 2 million characters).
code table (a drop down box with selectable values defined by your organisation in the associated Code table – usually up to 100 characters in length for each entry, optionally able to be presented as horizontal or vertical radio button lists as defined for that code table). Code tables are available for Statistics reporting.
multi list (a list of tick boxes, where more than one can be selected. The selectable values are defined by your organisation in the associated Code table – usually up to 100 characters in length for each entry). They appear in RefTracker as a comma separated list, and are available for Statistical reporting.
Request type ( a tree structure allowing selection of a Request type from the Request group and type code table values)
date (stores a date or a date and time)
check box (an easy way for the form user to indicate agreement – stored as Yes or No text).
Yes/No radio buttons (stored as Yes or No text in RefTracker).
money (stores amounts of up to 8 digits to which an International currency code applies – for example US dollars).
numeric (stores numeric data of up to 8 digits that can include digits past a decimal point).

These types are shown in the Type column of the Data dictionary table display (see example display of the Data dictionary Client table below). Where a field is a code table type field, the name of the associated code table displays in the Code table column, and the details of the code table are maintained using the Code tables function that can be accessed from the hyperlinked code table name.

You have control over the data entry fields that are available for use in your system because only fields that have been enabled (have Optional or Mandatory in the Enabled column) will appear in the Request forms design screen as fields able to be used in Request forms. Although this means that you can ensure only designated fields are used in Request forms, the most important feature of being able to disable/enable designated fields is that it ensures that the User defined fields are not made available for use in your system until you have specifically given them an appropriate name and enabled them.

Data box and Data area fields are named and enabled in the Data dictionary, however, Code tables must be named and enabled in the Code table function (and the enabled status that you set there automatically filters through to the Data dictionary).

Many RefTracker fields have names and purposes defined by RefTracker. Although you can apply standard RefTracker fields to suit your particular needs, even renaming them to indicate your specific use when appropriate, the choice of field you use must take into account any special functionality associated with that field, for example the “Client email” address is the field that RefTracker will look in when wanting to send an email to the client, so it would be inappropriate to use this field for a phone number for example. Similarly the “cc:” field is used to specify email addresses that will be copied on all emails, and the “cc: Answer” field is used to specify email addresses that will be copied on only the Answer when it is sent out – therefore these fields cannot be used for any other purpose. There are many other special purpose fields like these.

See the Appendix to the Administrator manual, for information about each of the fields and code tables that can be used in Request forms, and any special functions associated with these fields. It is essential that you take the information in that Appendix into account when choosing the fields to be used in your Request forms, so make a habit of referring to it to find the best field for the purpose you have in mind, from the wide range of fields available.

Many other RefTracker fields are “user defined”. The User defined fields have no specific functionality associated with them and so are free to be used for data collection, communication and statistical analysis according to the needs of your specific library. User defined fields (and User defined code tables) must always be appropriately named and enabled before they can be used, by using the Data dictionary or Code tables function in RefTracker to name and enable the field, before it can be used in Request forms.

Don’t forget that setting fields/code tables to Optional provides the greatest level of flexibility as an Optional setting allows lower levels in the hierarchy to be set independently. For example, if Age/Group is set to mandatory, it will be mandatory wherever it is used. But if you set it to optional, you can still manually set the DeskStats data table of the Data dictionary to Disabled so that Age/Group does not have to be collected in DeskStats, and in each Request form, you can then individually set the type of each use of the Age/Group field to Mandatory to ensure that this data is ALWAYS collected for full questions, or Optional as appropriate.