Entry import conflicts
What importing an entry list cannot settle on its own: each kind of conflict, an example, and how to resolve it — in the matching screen, then in the entry list, where kept conflicts stay in yellow.
In the matching screen
After Match with the database →, each row of the file has its state (Found, Proposed, Ambiguous, New) and its Matched athlete. The Conflicts column, in yellow, sums up what the row's choice leaves open (“date of birth different”, “race not kept: "Pursuits"”…); the full text is in the tooltip. It is redone at each choice: another record gives other differences, “Create a new athlete” shows the namesakes, “Ignore the row” leaves none.
At the end of the row, the Show this conflict box only appears if the row has a conflict. It is checked by default: a conflict that is not kept would be lost without a trace after the import, and keeping it costs only one click if it is accepted. It follows the row's choices as long as you have not touched it; unchecked by hand, it stays unchecked.
Checked, the row's conflicts are kept and highlighted in yellow in the entry list after the import. Unchecked, they are accepted as they are. Some conflicts only appear while writing (conflicting entry, duplicate bib, category not found, number refused): they are kept for every row whose box is checked, and for every row with no visible conflict (there was nothing to decide). The import report counts the kept conflicts.
In the entry list
Each kept conflict highlights in yellow the cell it concerns: Name and First name, G, Birth, Bib, Category, Group, or a race's cell. Hover over it: the tooltip gives the conflict, the row and file it comes from, and what to do (“Import conflict, row 3 of the file "entries.csv": …”).
The yellow goes away by itself as soon as the conflict is resolved: when the cell changes (in the list, in Athletes…, by a batch action or a reload), when the record takes the file's value, when a bib is no longer duplicated. Conflicts about the whole athlete (namesakes, record set aside, unreadable value, unknown race, number refused) are resolved by hand: right-click in the grid › Conflict resolved (remove the yellow highlight), or the Conflict resolved button of the batch bar, on the selected entries (otherwise on the displayed list), after confirmation.
The Import conflicts only box of the filter bar shows only the entries with a yellow cell; the status bar counts them (“6 import conflict(s) to resolve (cells in yellow).”).
The conflicts, one by one
For each one: when it appears, an example and what to do.
Athlete found several times
When: several records of the database match the row (same reference or number for several, same name, first name and date of birth for several, or same name and first name with a clue: year, club, gender). State “Ambiguous”, with no automatic choice; the row is in red.
Example: row 12, “Vasseur, Coralie, 2011”, and two records “Vasseur, Coralie”: 2011-01-02 at Club Est, 2011-08-30 at Club Nord.
What to do: in the matching screen, choose the right record in Matched athlete, or “Create a new athlete” if it is another person (Next to resolve goes to the next row without a choice). The choice settles the ambiguity; what remains (differences with the chosen record, namesakes of a new athlete) becomes one of the conflicts below.
Different data (name, date of birth, gender)
When: the matched record has another name or first name, another date of birth or another gender than the row. Cell: Name and First name, Birth or G.
Example: row 3 says “Lunel, Alix, 2010-05-05”, record R-201 says 2010-05-04. With “Fill in the record's empty fields”, the record keeps its date: Alix's Birth cell is yellow.
What to do: if the file is right, correct the record with Athletes…: the yellow goes away. If the record is right: Conflict resolved. With “Replace with the file's values”, the import takes the file's value and the conflict does not stay.
Record set aside: another member number
When: a reference or the name pointed to a record, but it has another member number in the same federation: these are two people, the record is set aside. Cell: Name and First name.
Example: row 7, “Roy, Denis”, no. 1001 of Fed A; the database record “Roy, Denis” has no. 2002 of Fed A.
What to do: check that these really are two people (otherwise correct the number and merge the records), then Conflict resolved.
New athlete despite namesakes
When: the row creates a new athlete although the database has namesakes (same name and first name, with no other evidence). Cell: Name and First name.
Example: row 9, “Petit, Emma, 2011-02-02”, creates a record; the database has “Petit, Emma (2012-07-01), Club Sud”.
What to do: if it is the same person, merge the two records (Athletes…, duplicates), then Conflict resolved; otherwise, Conflict resolved right away.
Duplicate row in the file
When: the row repeats a person already higher up in the file (same reference, or same name, first name and date of birth): it is ignored. What it brought on top of the kept row is a conflict of the kept row's athlete: a race (the race's cell), another bib (Bib cell).
Example: row 3 says “Roy, Denis, bib 7, 500 m”; row 14, same person, “bib 9, 500 m, 1000 m”. Denis's 1000 m cell and Bib cell are yellow.
What to do: check the 1000 m box if the entry is wanted, keep or change the bib: the yellow goes away when the cell changes. Otherwise, Conflict resolved.
Unreadable value
When: a value the reading did not understand is left empty: date, gender, country, language, time, yes or no of an “Entered” column, colour, min or max of a lap. Cell: Name and First name.
Example: row 5 has “31/02/2011” as date of birth: “unreadable value, left empty: Birth: date "31/02/2011" unreadable.”
What to do: complete the record or the entry, then Conflict resolved.
Entered race not kept
When: with the “Extract the entered races” option, a value that matches no race, that matches several (ambiguous) or that matches a race for the other gender than the athlete. Cells: each race the value could point to; Name and First name if it points to none.
Example: “Pursuits” on Coralie's row, while the event has “Team pursuit Women” and “Sprint pursuit Women”: both cells are yellow. “800m” on Emma's row: no race of that name.
What to do: before the import, choose the value's race in the extraction preview (“Race chosen by hand”, remembered with the format). After: check the right box — checking one of the races of an ambiguous value resolves all its cells. A value that points to nothing: enter the athlete by hand if needed, then Conflict resolved.
Race unknown to the event
When: an “Entered …” column or a race of the row is not a race of the event. The report lists it too (“Races not found (ignored)”). Cell: Name and First name.
Example: row 4 enters “800 m”, which the event does not have.
What to do: add the race (Races tab) then check its box, or enter the athlete in another race; then Conflict resolved.
Conflicting entry
When: the athlete was already entered (before this import, or by a row higher up) and the file replaces their bib, category, group or a race's entry time. Cell: Bib, Category, Group or the race's cell.
Example: Alix was entered with bib 12; row 3 gives her 15: “the athlete was already entered: the file replaced the bib "12" with "15"”.
What to do: keep the new value (Conflict resolved) or put the old one back in the cell: the yellow goes away as soon as the cell changes.
Duplicate bib
When: after the import, the bib of an imported entry is also worn by another entry of the event. Cell: Bib (already in bold red in the list).
Example: Coralie (row 2) and Denis (row 3) both have bib 7.
What to do: give each one their own bib, in the cell or with Bibs…: the yellow goes away for both as soon as the bib is no longer duplicated.
Category not found
When: the file's category is not a category of the event's speciality (neither by its name nor by its short name): it is left empty. Cell: Category.
Example: “Benj.” for a category named “Benjamin” (BEN).
What to do: choose the category in the cell, or Compute categories: the yellow goes away.
Number refused
When: a number of the row (member number, SpeedSkatingResults ID, platform ID) already belongs to another athlete: it is refused (two numbers, two people) and noted in the report. Cell: Name and First name.
Example: row 6, “Morin, Basile”, has no. 1001 of Fed A, already that of “Roy, Denis”.
What to do: check both records (typing error, or the same person to merge), then Conflict resolved.
Where conflicts are kept
With the event, in the database: another computer, or EVENT restarted, sees the same conflicts until they are resolved. Nothing changes in the database structure (FINISH keeps opening it). A new import adds its conflicts to the others; a conflict of the same kind on the same cell replaces the old one. The tooltip's explanation is written in the interface language when you read it.