Complex Table Fields

A complex table field definition defines a field in each record of the table, including the data type of the field and the size of the data the field can store. A record within the table can consist of multiple fields of varying types and sizes.

A Complex Table is made up of records on the Agentry Client. Each record in the table is made up of Fields. Within a Complex Table definition in the Agentry Editor, you define the fields that make up the table’s records.

Complex Table Field Settings

• Name: This is the name used to uniquely identify the field within the Complex Table.
• Display Name: This is the text value displayed on the Agentry Client to for the field. This includes the column headers in a Complex Table Search screen, as well as other places.
• Type: This attribute specifies the data type of the field. This is discussed further shortly.
• No. of Characters: This attribute is available only for one of the String type of fields and specifies the maximum number of characters the field can hold. Note that this is not necessarily the same as the number of bytes, as is explained in the section of the field data types. When setting this attribute, the value should be large enough to accommodate the strings the records will contain. However, it should not be simply set to an overly large value, as this will waste significant resources on the Client, both in storage and memory.

Field Data Types

There are six data types possible for a Complex Table Field definition. Each controls, first, the type of data that can be stored in the field and, second, how that data is sorted within the table. This last aspect can have a significant impact on how a user can search the complex table on a particular field. Following, each of the data types for a field are listed, along with a description of the impact each type has.

• ASCII String (case-insensitive): This field type specifies that the field will contain string characters, each one byte in length. This will support the standard ASCII characters. The case-insensitive portion indicates that, when the table is searched or sorted on this field, the case of the characters is not considered. That is, the lett ‘A’ is treated as equal to the letter ‘a’.
• ASCII String (case-sensitive): This field type specifies that the field will contain string characters, each one byte in length. This will support the standard ASCII characters. The case-sensitive portion indicates that, when the table is searched or sorted on this field, the case of the characters is considered. That is, the letter ‘A’ will be sorted after the lett ‘a’.
• International String (case-insensitive): This field type specifies that the field will contain string characters in the UNICODE format. This supports the non-english language characters, such as those in Hebrew or Chinese. Note that this also includes characters with an accent mark. This field type will still include the ASCII characters, as well. The case-insensitive portion indicates that, when the table is searched or sorted on this field, the case of the characters is not considered. That is, the letter ‘A’ is treated as equal to the letter ‘a’.
• International String (case-sensitive): This field type specifies that the field will contain string characters in the UNICODE format. This supports the non-english language characters, such as those in Hebrew or Chinese. Note that this also characters with an accent mark. This field type will still include the ASCII characters, as well.
• Number: This field type specifies that the field will contain numeric values only. These values may be whole numbers or decimal values and may be positive or negative. If you wish to index a field containing numerical values for the purpose of providing search functionality to the user on the Agentry Client, that field type should be string. Currently, Agentry does not contain the control types on the Agentry Client to support searching numerical values in a complex table.
• Identifier: This field type specifies that the field will contain numeric values only. These values may only be whole, positive values. Decimal and negative values are not supported. The purpose of this field type is to explicitly support an identifier field for each record. Note that this is not a requirement, as the other field types can also be used as the identifier value for a record. This is covered in detail in the section in Indexes later in this chapter.