Table field indexing considerations

You can enable table fields to be searched in multiple-form searches, but not in regular full text searches. If a table field is indexed, the server retrieves only the character data and ignores columns of other data types such as columns from numeric data fields. The server concatenates the character data from the table and inserts a space character between the data from the fields.

For example, consider the following table is indexed.

Related topics

Rebuilding-an-index-for-specific-fields

Defining-a-field-for-FTS



This table would generate the following character string for indexing:

Sent email to customer Demo Still waiting to hear from customer. Demo Customer responded. Demo

A string like this is created for each entry in the parent form by using the table field rows that correspond to that parent form entry.

Consider the following caveats when indexing table fields:

  • All rows that qualify are indexed, even if only a subset of rows is displayed to the user, resulting in the search hits for rows the user cannot see.
  • Permissions and row-level security are not enforced during searching, so users might see data from table field columns they cannot view.
    Highly sensitive data should not be indexed for multiple-form searches.
  • AR System server does not index table field indexes automatically when new entries are added or existing entries are changed, so the indexes should be manually re-indexed.
    To keep indexes up to date, create a workflow to re-index the table field when you make changes.
  • A few table fields, such as those with certain qualifications, might not be eligible for indexing.
    A workaround is to create a copy of the table field with simpler qualifications containing only database fields and index the copy instead. This method allows the indexing of all visible table data.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*