Dear All,
It means the current version of epidata manager/client is not supporting the unique key check if it is noenter. As it is working fine in Epidata 3.1 classic.
Thanks & best regards, Rasool Bux
-----Original Message----- From: epidata-list-bounces@lists.umanitoba.ca [mailto:epidata-list-bounces@lists.umanitoba.ca] On Behalf Of epidata-list@lists.umanitoba.ca Sent: Tuesday, September 16, 2014 2:16 AM To: epidata-list@lists.umanitoba.ca Subject: Re: [EpiData-list] Epidata Manager key unique handling
Hi Rasool and Jamie.
On 2014-09-15 17:13, epidata-list@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. _______________________________________________ EpiData-list mailing list EpiData-list@lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list
________________________________
This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately.