Indexing table fields

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, suppose the following table is indexed.

This table would generate the following character string for indexing:

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

Consider the following caveats when indexing table fields:

• All qualifying rows are indexed for the table field, regardless of the maximum rows value set for table field entry retrieval.
   For example, if you limit table field retrieval to 100 rows but 110 entries qualify, the server includes all 110 entries in the character string it builds. If a search term is found only in the 10 entries the user does not see, it may not be apparent why the table field qualified as a search hit. However, if the table is re-sorted, the search term could appear in the resorted entries. (Note that table-field chunking is not relevant to indexing, but a search term might not be displayed in the chunk the user is viewing.)
• Permissions and row-level security is not enforced during searching on table fields, so a user could potentially retrieve search hits from table field columns that the user cannot view.
   Because character data is concatenated for table field searches, the server cannot eliminate the data from inaccessible columns. If a table field contains highly sensitive data, you should not index it for a multiple-form search.
•  does not automatically detect when entries are added or changed in a supporting form, but the parent form entries should be re-indexed.
   You can manually re-index a table field to keep the index up to date, but no automatic solution exists. Instead, to keep table field indexes up to date, create workflow that pushes updates to the parent form entries when changes are made to entries in the supporting form. When a change is detected in the parent form entry,  re-indexes the entry, including the table field. Some applications update only the table field supporting the form through parent form interaction. In those cases, the parent form might already be experiencing an update, and additional workflow is not necessary.
• Some table fields are not eligible for multi-form search indexing. If the table field qualifier has EXTERNAL qualifications or display-only field references and the Index for MFS field property is set to True, an error is returned when the user tries to save the form.
   In many cases, you can achieve the necessary search functionality by creating a copy of the displayed table field and making that copy a hidden table field on the form. This hidden table field can have a simpler qualification containing only database fields, making it eligible for multi-form search indexing. The goal is to index (in the copied table) all of the table field data that can be seen when viewing the displayed table field. Many times the additional qualification clauses that contain display-only fields are used to dynamically filter the table field rows. By removing those clauses, the indexing occurs on all the rows in an unfiltered manner. Because multi-form searching is not field specific, indexing a copy of the field with a modified qualifier can produce the necessary results.