Altova RecordsManager

Repositories and Data Containers

Your application created in Altova RecordsManager can be comprised of one or more repositories, each of which includes multiple data containers.

All configuration is done using AI tools and a straightforward visual interface. No coding or backend database development is required. What’s more, you can reconfigure the repositories, add new forms, change settings, and carry out other administration tasks even after users have started working with the system. Any admin changes you make will be reflected on the user side as soon as the user interacts with the system.

As you set out to configure the structure of the data stored in your app, the sequence is roughly that shown below, though RecordsManager is flexible and new items can be added at any phase of the design process.

1. Create repository(s) and data containers, and set up a hierarchy
2. Configure fields
3. Configure forms
4. Configure filters
5. Design the home page for your app


At the root level of your app, you can create one or more repositories. Repositories help organize data containers to differentiate between data areas. Repositories are used for organizational purposes only: data containers can be moved between repositories at any time, even after data has been entered.

Define one or more repositories in RecordsManager

You can apply different color themes to each repository for clear differentiation, as shown above with the Contact and Company repositories.

Database checkpoints

Because you can change the structure of your database and its data containers at any time, even after data has been entered, database checkpoints are an important fail-safe. These allow you to make a complete copy of the whole database including the structure, access configurations, and user data. When used as a safety precaution before making important structural changes, you can restore the whole database to the last-known-good checkpoint with a single click.

Styling Your Repositories

The system comes with multiple built-in color themes that you can choose to style your app. Then, each repository that’s part of the system can use a different variation on that theme, if desired. What’s more, users can customize the app themselves by changing the color theme as desired while working.

Configuring the database color theme

You as admin can easily customize the font size, require field titles to be all capital or low/camel case, apply bold and italic styling to certain fields, and so on. End users can still adjust the overall font size to optimize viewing in their browser or mobile device without sacrificing the form design provided by the admin.

Edit font styles and appearance in RecordsManager

There is an additional setting for size translation when the forms are used for printing.

Setting print settings in RecordsManager

RecordsManager supports an image library so that you can use images throughout the design. One of these images can be designated as a company or app logo, which will be displayed on all main pages in the system.

Data Containers

Data containers are similar to tables in SQL databases in that they consist of records with fields. However, unlike SQL tables, data containers in RecordsManager give you the flexibility to add, remove, change, and/or re-order fields at any time.

Within each repository, you can add as many data containers as you like.

Within a top-level container (as well as lower level containers), you can add multiple child containers. You can continue adding child containers down multiple levels. End users’ data will be stored as the records of data containers.

Add a data container to your online database

Each data container is defined by a set of fields, in which the data of records is stored. Shown below are fields defined for a Department data container.

Defining fields in the online database

When defining the database structure, you will be building relationships between containers to reflect the hierarchy and organization of the data therein. There are two kinds of relationships between data containers: parent-child and loosely linked.

Parent-child data containers

Parent-child definitions are considered strong links since a child is created from a parent and cannot be created without the parent. A parent container can have multiple child data containers. A child, however, can have only one parent container. The following consequences of the parent–child relationship should be noted:

  • Requires data in parent container before child data can be entered
  • When a parent record is deleted, all child data is recursively deleted too
  • When designing forms, the fields of all ancestor data containers will be available for inclusion
  • Filters can use parent data for filtering too
  • Child records can be edited within parent forms

In the view below, a parent-child relationship exists between the company, department, and person fields.

A parent-child relationship in the online database

A second type of relationship is a link that is created between two independent data containers. These loose links enable records to be created independently and without reference to each other. The links are manually created during configuration. A single record can thus have multiple loose links to other records. If one record of a loosely linked pair is deleted, the other record is not affected.

In the view above, Company Group and Company are loosely linked.

Notable characteristics of loosely linked data containers:

  • Child records can be created first and assigned to their parent later
  • Parent records can be deleted – the child records will remain
  • A child record can reference multiple parent records
  • Parent forms are able to show child records without editing

Loose links can be set in the following ways:

  • Defining the field of a container to be of type Link To. This field provides the anchor of the link to the other container.
  • Converting child data containers that have a strong relationship to their respective parents to a loose link

Links in RecordsManager are extremely flexible. The administrator can change between both types of relationships – even if data has already been entered. The system will create the new data structure as closely as possible and existing forms will be adapted accordingly.

Changing parent/child and loose links in the database

As you’re working it’s easy to insert new data containers between parent and child containers, and you can even remove parent or child containers and the system will adapt the remaining data structures.

Adding data containers to the online database

You can either define a data container from scratch, duplicate an existing container as a starting point, or import existing data.

Single Record Option

RecordsManager includes an option to indicate a data container consists of just one record (for example, a master file about the owner company). When choosing such a data container, the user won’t be presented with a record list and will immediately get to edit the record. Since it’s a single record container, the user won’t have the option to add or delete records.

Importing data

It’s also possible to perform a mass update of existing records to modify fields via XPath, either with a fixed value or based on other fields. You can update all records or preselect some records using a previously defined filter. During the update, you can preview changes that will be made before actually running the mass update.

What’s Next?

After visually defining your repository and container hierarchy, create some fields for your data containers.

Get Started with RecordsManager

RecordsManager is a free, pre-built MobileTogether solution that is available for you to start using when you install MobileTogether Designer. Use the link below to download and install the free Altova MobileTogether Designer to get started on your first RecordsManager app.