The system can be used by multiple users at the same time and update conflicts can arise in some circumstances.
This will not normally be an issue as scoring teams are small, < 10, and will expect to collaborate and adopt rules such as "team A scores odd numbers, team B even numbers", etc but conflicts are theoretically possible.
EBC judging
If an EBC claim is pulled by two different judges, each will update the EBC record and post the resulting claim records with the last one actually applying. This will result in two claims appearing on the claims log.
It would be better if the first judgment succeeded with later judgments being either silently dropped or dropped with a notification to the rejected judge. Silent dropping can be achieved by amending the UPDATE to include the WHERE condition "Processed=0".
Manual claim logging
Where two individuals post the same claim, the last one posted will be apply. This will result in two claims appearing on the claims log.
There is no simple remedy for this as submitting multiple "same" claims is expressly permitted. Reviewers should simply delete extra claims to keep the printed claims log accurate.
Scorecard updating
If two scorers simultaneously update a scorecard the first update will be silently overwritten by the second. This might well be a problem where different scorers are processing individual bonus claims as some scoring information could be lost. The first attempt at preventing this situation involved setting the ScoringNow flag on the entrant record during the read to prevent multiple access but this method proved problematic and has been abandoned.
A better approach would be to use a new field LastUpdateNumber on the entrant record, incremented with each update. When reading the scorecard, the LastUpdateNumber is recorded and during save the UPDATE uses "LastUpdateNumber=LastUpdateNumber+1" and WHERE clause "LastUpdateNumber=n" with failures being reported back with conflict resolution options. The same technique should be applied to other entrant record updating.
Scorecard / claims log updates
In a rally scored by individual claims processing conflicts might arise if direct scorecard updating is also used but this should not happen in practice as rallies will almost always be either claim by claim or scorecard by scorecard. Manual control is the best method of managing this.
The system can be used by multiple users at the same time and update conflicts can arise in some circumstances.
This will not normally be an issue as scoring teams are small, < 10, and will expect to collaborate and adopt rules such as "team A scores odd numbers, team B even numbers", etc but conflicts are theoretically possible.
EBC judging
If an EBC claim is pulled by two different judges, each will update the EBC record and post the resulting claim records with the last one actually applying. This will result in two claims appearing on the claims log.
It would be better if the first judgment succeeded with later judgments being either silently dropped or dropped with a notification to the rejected judge. Silent dropping can be achieved by amending the UPDATE to include the WHERE condition "Processed=0".
Manual claim logging
Where two individuals post the same claim, the last one posted will be apply. This will result in two claims appearing on the claims log.
There is no simple remedy for this as submitting multiple "same" claims is expressly permitted. Reviewers should simply delete extra claims to keep the printed claims log accurate.
Scorecard updating
If two scorers simultaneously update a scorecard the first update will be silently overwritten by the second. This might well be a problem where different scorers are processing individual bonus claims as some scoring information could be lost. The first attempt at preventing this situation involved setting the ScoringNow flag on the entrant record during the read to prevent multiple access but this method proved problematic and has been abandoned.
A better approach would be to use a new field LastUpdateNumber on the entrant record, incremented with each update. When reading the scorecard, the LastUpdateNumber is recorded and during save the UPDATE uses "LastUpdateNumber=LastUpdateNumber+1" and WHERE clause "LastUpdateNumber=n" with failures being reported back with conflict resolution options. The same technique should be applied to other entrant record updating.
Scorecard / claims log updates
In a rally scored by individual claims processing conflicts might arise if direct scorecard updating is also used but this should not happen in practice as rallies will almost always be either claim by claim or scorecard by scorecard. Manual control is the best method of managing this.