Altova RecordsManager

This section describes the Database Structure tab of the Configuration Page. This tab provides access to all the forms that are used to define and present the structure of your RecordsManager database.

The app's repositories

The app can contain one or more repositories at the root level, each of which will contain the data tables of RecordsManager. In our sample app (see screenshot below), there are two repositories: Contract Database and Company Database. Within each repository you can build a hierarchical structure of data tables, and you can link data tables across repositories via loose links.

Data tables and hierarchy

A hierarchical structure within a repository is constructed by creating data tables and then defining parent–child relationships between data tables. You can add any number of top-level data tables to a repository. Within each data table (top-level or other level), you can define one or more child data tables. You can use loose links to link data tables across the different hierarchies of a data table.

For example, in the screenshot above, there are three top-level data tables: Contract (in the Contract Database repository), and Company Group and Company (in the Company Database repository) Of these three data tables, only the Company data table has a child data table (the Department data table), which itself has a child data table (the Person data table). Note that, while a parent can have multiple child data tables, a child can have only one parent.

Each data table has a set of definitions (shown below for the Person data table). The most important of these are: the data table's fields, the forms designed for the data table, and the filters to restrict data selection. These definitions are described in their respective topics: Data Tables, Fields, Filters, and Forms.

Records

When data is entered, it is entered as a record of a data table. For example, records of all persons are entered as records of the Person data table. These records are entered in a (data) entry form of the Person data table, which is designed to contain data entry options for fields of the Person data table (such as Name, ID, and Email). The Person entry form would also contain an option to link the Person record to a field value of another data table (for example, to the Legal department, where Legal is the value of the Department data table's Name field). In this way, a relationship is built between Person records and another data table, say the Department data table. It is through these relationships that records in different data tables are linked and the data is available for structuring. For example, it would now be possible to list, say, all the persons in a company's different departments, or all the software contracts that expire in the next quarter.

Also see How the App's Data Is Structured.

Search the RecordsManager database

The button to search all the repositories of the database is located at the top of the Database Structure tab, near the Home Page button. It is circled red in the screenshot below..

When you click this Search All button, the Search Whole Database form appears (screenshots below), which has as its search scope all the repositories of the RecordsManager database.

The form has tree tabs: Fields, Filters, and Forms. Each shows, respectively, all the fields, filters, or forms in the search scope. Select the tab you want. To sort the displayed items, select Sort alphabetically.

You can now select one or both search criteria:

•By Type: A combo box appears that enables you to select from the available types. For example, in the Forms tab shown in the screenshot above, the type of form that has been selected to search for is the report form type. The screenshot above left shows all the report forms in the search scope, sorted alphabetically.

•By Name: In the entry field for this criterion enter the string to be searched for in the names of fields, filters, or forms. In the screenshot above right, we search for report forms that have the string "category" in its name. Search strings are case-insensitive.

If both criteria are selected, then the search returns an intersection of the results of the two searches,