Tables are used to capture information where multiple values are required for a single field. Tables can only be built such that each question field is a column (row based tables are not possible in Smartabase) and all the question types available in the **Add Question** tab of the form builder can be used in a table. The only exception to the question types which can be used in a table are the five types of table calculations. This is because table calculations reference the contents of a table and will not work as expected when included in a table.

Setting up the advanced properties for a table is a little different to doing so for a normal field. These properties are all set using the **Advanced Properties** tab of the first field of the table. In addition to the usual advanced properties for the first question type in the table, it is possible to set the number of rows shown by default, allow or disallow the functionality of adding more rows and lock completed rows, among other things. Keep in mind that if you delete the first field or move it elsewhere in the table, the table’s properties will reset to whatever properties the new first field has.

**EXAMPLE: STRENGTH AND CONDITIONING FORM TABLE**

This example shows a table used in a strength and conditioning form. The first question in the table, on the left-hand side, is called **Exercise** and is a database question. Each of the subsequent columns is a question that has also been set to appear in table format. In the example shown above, **Exercise** holds the table properties for the entire table.

Tables are not restricted to being used for data entry fields. It is possible to run calculations within a table. In this example, the field **Load** is a calculation multiplying the data entered for the fields called **Sets**, **Reps** and **Weight**, as follows:

`Sets * Reps * Weight`

It is important to keep in mind that if a calculation references another field in the table, it will only take into account the value on the same row. In this example, **Load** in row 1 is using the values on row 1 for **Sets**, **Reps** and **Weight**. The same process will occur for **Load** in row 2, row 3 and so on. It is not possible for **Load** in row 1 to use values from any other row. To calculate values for multiple rows, it is necessary to use table calculations (in this example, **Total Session Load**, **Maximum Intensity** and **Total Sets** are table calculations).

Builders should not forget that as with any other calculation type, calculations that use mathematical operators will not run unless all referenced fields are filled in. So when **Sets**, **Reps** and **Weight** are referenced by the calculation called Load, the Load calculation will not run until **Sets**, **Reps** and **Weight** contain data. This is not a problem in this example because you need each of these values to calculate a meaningful result about the training load. However, as in the following example, the user might complete a table without filling out all of the fields which are referenced by a calculation.

**EXAMPLE: A TABLE WITH VARIABLE AMOUNTS OF DATA**

This example table contains questions called **Split 1**, **Split 2 **and so on through to **Split 10**. There is a calculation in the last column called **Total Time (Ss.S)** for the purpose of displaying the total of all split times per row. For the purpose of this example, assume the calculation uses the following formula:

**Split 1 + Split 2 + Split 3 + Split 4 + Split 5 + Split 6 + Split 7 + Split 8 + Split 9 + Split 10**

In this example, a user has filled out a table relating to a training session with data from six splits in the first row, five in the second and 10 in the third. Because this calculation references all of the split fields and uses mathematical operators, it will not return a result unless all the split times are filled in. This is why the **Total Time (Ss.S)** only contains a result in the third row; however, calculating the total time for the incomplete rows would also be considered a meaningful result.

To solve this problem, the **Safe** function can be used to treat blank fields as if they contain the value of zero. This means that, if used in the example above, the following calculation would return results for all rows, regardless of empty fields:

**Safe(Split 1) + Safe(Split 2) + Safe(Split 3) + Safe(Split 4) + Safe(Split 5) + Safe(Split 6) + Safe(Split 7) + Safe(Split 8) + Safe(Split 9) + Safe(Split 10)**

Note that this function normally would not be used for fields that are to be divided or multiplied, as the calculation will return a result of zero.

An alternative solution to the problem identified in this scenario would be to avoid the use of mathematical operators by using the

Sumfunction as follows:

**Sum(Split 1, Split 2, Split 3, Split 4, Split 5, Split 6, Split 7, Split 8, Split 9, Split 10)**

**EXAMPLE: A TABLE VIEWED USING THE REPORTS MODULE**

When setting the advanced properties for fields within the table, builders have to be mindful about how fields within a table show up when viewed using the ** reports** module or the user

**. In this example it can be seen that one record of the strength and conditioning event form shows up over five rows instead of one. This happens because the table within the form has five rows and therefore five records for**

*history***Exercise**,

**Sets**,

**Reps**and so on. For this reason, it is usually good practice to set all table fields to not appear in

*and the user*

**reports***(Default Show In Tables would be set to*

**history****False**).

If the data contained within the table must be shown in reports, a solution for the multiple row problem would be to summarise the table’s contents using a table calculation or table text calculation and display this calculation in reports.