[EpiData-list] Epidata Manager key unique handling

epidata-list at lists.umanitoba.ca epidata-list at lists.umanitoba.ca
Mon Sep 15 16:15:52 CDT 2014


Hi Rasool and Jamie.

On 2014-09-15 17:13, epidata-list at lists.umanitoba.ca wrote:
> Hi Rasool,
>
> I had a look at your file (thanks for sending it). Here is the problem - something for the development team to address.
>
> Problem: The key field is a calculated field, based on 3 other must enter fields and it is no-enter. Because the user does not enter this field, it’s uniqueness is only checked at the time when the record is being saved. Then you cannot save the record, as you will have seen. Problem 2: the user is not told that there is a duplicate key; the record just cannot be saved.
>
> Workaround: Put the key field in a position immediately following the 3 fields used to calculate the field. Turn off NO ENTER and ask the users to NOT change this field. When the user hits the <enter> key, the duplicate is identified.

No, do not use that workaround. The problem is that we allowed 
calculated fields to be part of a key in the first place. It is entirely 
possible to use many fields as part of a key. Eg. using an identifier 
specific for a hospital in combination with a date AND a counter.

This will ensure that for any given record you can store data where the 
cobination (HospID, VisitDate, EntryNo) is always unique.

The way of creating a single calculated field for a key for use as a 
unique identifier, is a leftover solution from the old EpiData 3.1 which 
did not allow specifying multiple fields as part of a unique key.

Although i haven't seen your project, my guess is that this is the case 
and could easily be solved by specifying the fields involved in the 
calculation, as the unique key.

>
> Solution for the long term: Entry Client should check whether a calculated field is KEY and if it is, then the check for duplicate should be performed when the field is calculated.
>
> Note to  Jens & Torsten: The same problem arises, if the 3 fields are declared KEY, rather than calculating the key. The only time the uniqueness of the resulting key is checked is when the record is saved.
Again, the entire key is validate after all fields in the key have been 
entered. If one of the fields involved is an automated field where the 
value is not updated untill after records is saved (using "Update on 
Save" on the extended page) the key-check will never be valid. However, 
I do agree that a proper errormessage should be displayed.


Regards,
Torsten Bonde Christiansen.
EpiData.


More information about the EpiData-list mailing list