Common errors in a form

FormShare manages your data in a better way but by doing so it performs more checks on your ODK Form. Though FormShare follows ODK's official standards it has more restrictions, for example, if you have an ODK form with a variable called "repeat" it will not upload in FormShare nor in Kobo because "repeat" is an ODK restricted word, however, if you have a variable called "abstract" the ODK form will upload in Kobo but not in FormShare because "abstract" is a restricted word in FormShare. For this reason, if you have an ODK Form that works on other platforms it might need some modifications to work with FormShare. The platform will inform you about the error and how to correct it.

This section provides information about the common errors in a form

The primary key does not exist

Message from FromShare: "The primary key variable does not exist or is inside a repeat."

When you upload a form FormShare asks you to indicate a variable to use to control duplicate submissions:

The variable to control duplicate submissions must exist in your form and it must be OUTSIDE a repeat.

What is duplicate data?

Let’s imagine that you are surveying cattle in a rural village and each animal has an ear tag. Two enumerators, James and Patricia go around the village gathering the information for each animal. James and Patricia without realizing it, survey the same animal (the same ear tag) and send the data. To solve this problem and prevent having the same animal twice in our dataset, you can tell FormShare that the ear-tag variable must be unique. In this example, the ear tag is the variable that you will use to control duplicated data. FormShare will alert you that there is duplicated data, and you will be able to correct it easily.

To fix this problem, select a different variable or move the variable that you want to use outside any "repeat".

Duplicated variables

Message from FromShare: The following variables are duplicated within repeats or outside repeats

The ODK standard allows having two or more variables with the same name as long as they are in different groups. FormShare does not allow that and will tell you which variables are repeated. Just rename the variables to fix the problem.

Variables with invalid names

Message from FromShare: The following variables have invalid names

This error occurs when you have a variable that is also a restricted word in FormShare. The following is a list of restricted words that you CANNOT USE as variables or repeat names.

FormShare will tell you which variables have invalid names. Fix the problem by renaming the variables.

Identical choice lists

Message from FromShare: The following choice lists are identical.

This error happens when two or more choice lists in the "Choices" sheet have the same options/items. The example below has the problem, the choice list sexˍowner is identical to the choce list sexˍpet.

To fix this error you need to use only one list. The error above can be solved by having only one list called "sex" and use it for both variables. See example:

Mixing coded and not coded languages

Message from FromShare: This ODK form mixes coded and not coded languages. For example label::English (en) and label::Español. You need to code all the labels that are marked for translation.

FormShare is able to store the description of variables and options in multiple languages. The ODK standard for translating an ODK has evolved over time. In the beginning, the translation of an ODK was done using, for example, label::Español. Currently, it is done by adding the ISO 639-1 code, for example, label::Español (es).

Please note that you need to have a space between the description of the language and its code. The standard is label::[Language description][space]([language code])

In FormShare you cannot mix coded and not coded languages. To fix this problem you need to code all the labels that are marked for translation, for example, change label::Español to label::Español (es)

The variable to control duplicate submissions has an invalid type

Message from FromShare: The variable to control duplicate submissions has an invalid type. For example, this variable cannot be note, picture, video, sound, select_multiple, or geospatial. The most appropriate types are text, datetime, barcode, calculate, select_one, or integer.

When you upload a form FormShare asks you to indicate a variable to use to control duplicate submissions:

The variable to control duplicate submissions cannot be a note, picture, video, sound, select_multiple, or any variable of the geospatial type.

What is duplicate data?

To fix this problem, select a different variable to control duplicate data.

Tables with a name longer than 64 characters

Message from FromShare: FormShare needs you to shorten the name of some of your tables. The following tables have a name longer than 64 characters...

FormShare stores submissions as relational data. This means that it creates tables with columns in a database to store your data as rows. There is a whole section in this documentation to explain how does FormShare stores your data, however, to explain this error it is important to understand when FormShare creates tables. FormShare creates tables in these three circumstances:

A table called "maintable" is created to store all variables that are outside any "repeat" structure.
Every "repeat" structure creates a table. The name of the table will be the name of the repeat.
Every variable of type "selectˍmultiple" or "rank" create a table to store each selection or each rank as independent rows. The name of the table will be [parentˍtable]ˍmselˍ[variableˍname]. For example:

A "selectˍmultiple" variable named "gender" outside any repeat will create the table called "maintableˍmselˍgender".
A "selectˍmultiple" variable named "livestock" inside a repeat named "livestock_repeat" will create a table called "livestockˍrepeatˍmselˍlivestock".

FormShare uses MySQL to store submissions as relational data and MySQL restricts the name of tables to a maximum of 64 characters. This error indicates that one or more tables have a name with more than 64 characters. There are different ways that the error may happen:

To correct this error you need to rename the name of the variables.

It would be best to use short names for your variables. FormShare has a data dictionary and you will be able to work with variable descriptions.

CSV files with invalid characters in column headers

Message from FromShare: The following CSV files have invalid characters in column headers

FormShare can read external CSV files and import their contents into the database. For example, FormShare will read the CSV file of variables like "selectˍoneˍfromˍfile" or "selectˍmultipleˍfromˍfile" and load the options into the database. The column headers must NOT contain any special characters like spaces or commas. Underscore (_) is the only character that is allowed in column headers.

Fix this problem by replacing spaces with underscores and removing any other characters.

CSV files with an invalid structure

Message from FormShare: The following files have an invalid structure.

FormShare can read external CSV files and import their contents into the database. For example, FormShare will read the CSV file of variables like "selectˍoneˍfromˍfile" or "selectˍmultipleˍfromˍfile" and load the options into the database. This error happens when the CSV is corrupted, for example, when the file has 4 headers separated by a comma but a row has 5 values separated by a comma.

Fix this problem by checking the file in a CSV reader like MS Excel.

Choice list with duplicate option

Message from FormShare: The following options are duplicated in the ODK you just submitted

What are cascading choices?

Cascading choices are sets of choice lists whose options depend on the selection of a previously selected option in another list. For example, your form may first ask the region where a respondent is from, and then in the next question list only the towns of that region.

You can design your ODK in such a way that in the choice list of towns the town code may repeat itself, however, it will be unique within the context of a region. This is not a good practice.

To facilitate analysis, choice codes/names should be unique within a single choice list. If two choices from the same list have the same code/name, even if they are unique within the context of an earlier selected option, it will be harder to tell apart in an analysis.

In an ODK you can have cascading choices with duplicated options by marking the "allowˍchoiceduplicates" setting as true. However, FormShare does not allow duplicate options. FormShare supports cascading choices but you need to make each choice unique no matter the context. Using the above example, you can make the town code unique by concatenating the code of the region [regionˍcode]-[townˍcode].

Why FormShare does not allow duplicate options?

FormShare stores submissions as relational data. Choice lists are stored as lookup tables, for example, the choice lists called "regions" will create the lookup table called "lkpˍregions". Each lookup table has a primary key, for example, the primary key of the lookup table of "lkpˍregions" is "regionsˍcode". A primary key must be unique and this is why FormShare does not allow duplicate options.

Fix this problem by making unique all codes/names within an option list.

Malformed language

Message from FormShare: Malformed language in your ODK. You have label:X (Y) when it must be label::X (Y). With two colons (::).

Please note that:

You need to have two colons (::) to indicate translation. For example, label::
You need to have a space between the description of the language and its code. The standard is label::[Language description][space]([language code])

FormShare is indicating that some of your translations have only one colon, for example, label:Español (es). Check your translations and fix the problem by adding a second colon.

Choice list with names but not labels

Message from FormShare: You have choice lists with names but not labels. Did you missed the :: between label and language? Like label:English (en)

Please note that:

You need to have two colons (::) to indicate translation. For example, label::
You need to have a space between the description of the language and its code. The standard is label::[Language description][space]([language code])

FormShare is indicating that in the "choices" sheet there is a label with only one colon. For example label:English (en). Check your labels in the "choices" sheet and fix the problem by adding a second colon.

Tables with more than 60 selects

Message from FormShare: FormShare manages your data in a better way but by doing so it has more restrictions. The following tables have more than 60 selects

Why FormShare has this restriction?

FormShare creates a relational database to store the submissions by reading the structure of your ODK. This is covered in detail in the section "How does FormShare stores my data?" but for now two points are important to describe this error:

FormShare stores "repeats" as separate tables, however, "groups" are not.
FormShare stores all variables (questions, notes, calculations, etc.) outside repeats into a table called "maintable".

We tend to organize our surveys in sections with questions around a topic. For example: "livestock inputs" or "crops sales". These sections have "type = begin/end group". Because FormShare does not create tables for "groups" if your survey has many questions then "maintable" will end up with several columns. If your survey has many selects across several groups, then the "maintable" could potentially have more than 60 selects. FormShare can only handle 60 selects per table.

Why FormShare can only handle up to 60 selects per table?

FormShare stores your submissions in a MySQL relational database. MySQL supports up to 64 indexes per table (see MySQL scalability and limits). FormShare puts such restriction in 60 to take into account primary keys.

This restriction can appear in "maintable" or in any "repeat". FormShare will tell you which table/s overpass this restriction.

How to bypass this restriction?

You can bypass this restriction by enclosing your groups inside "repeats" BUT WITH "repeat_count = 1". A "repeat" with "repeat_count = 1" will behave in the same way as a "group", but FormShare will create a new table for it to store all its variables. This will separate your sections into different tables but also will make your data more structured and more understandable for others.

The following example is a real ODK survey that will report more than 60 selects in "maintable". The example also shows the different topics across the survey and has a possible solution to bypass the restriction in the sheet called "survey_fixed".

How to use control variables inside a repeat

When you separate sections of your survey inside "repeats with repeat_count = 1" the variables within are not directly accessible in other sections of the survey. However, you can extract them from a repeat using a "calculate" with the function:

indexed-repeat(${variableˍtoˍextract}, ${repeatˍname}, 1)

See line 661 in the sheet "survey_fixed" of the example above.

PreviousForms NextAssistants

Last updated 1 year ago