All you have to do, is to define a key, which you find under project properties. After definition of a key, only one observation can be entered for each value.
In entryclient a key is always what was "key unique" in Classic Epidata 3.1.
Regards Jens Lauritsen
epidata-list@lists.umanitoba.ca skrev:
Dear all,
I have tried to use epidata manager & client. The Entry client is not indicating on duplicate entry of id field as in Epi data classic 3.1. Please let me know if there is any option to give message just after entering the key field and stop the entry to next fields.
Thanks & best regards, Rasool Bux
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. _______________________________________________ EpiData-list mailing list EpiData-list@lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list
I have done that but during data entry it is not stoping on duplicate ID entry. At the end of last field entry it is not moving for second record.
Thanks, Rasool Bux
epidata-list@lists.umanitoba.ca wrote:
All you have to do, is to define a key, which you find under project properties. After definition of a key, only one observation can be entered for each value.
In entryclient a key is always what was "key unique" in Classic Epidata 3.1.
Regards Jens Lauritsen
epidata-list@lists.umanitoba.ca skrev:
Dear all,
I have tried to use epidata manager & client. The Entry client is not indicating on duplicate entry of id field as in Epi data classic 3.1. Please let me know if there is any option to give message just after entering the key field and stop the entry to next fields.
Thanks & best regards, Rasool Bux
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. _______________________________________________ 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.
Which build are you using? With v2.0.0.0 (RC1), I cannot enter a duplicate ID (the ID field is the KEY for relate). If I do, I am asked whether I want to go to that record.
When I have entered a child record (with the setting to allow only one child record) (Dataform 2), I am returned to the parent record (Dataform 1) IF there are more fields to enter. If I did the relate on the last field in Dataform 1, then I am taken to a new record on Dataform 1.
Perhaps we are setting things up differently. When the bugs are worked out, a couple of simple answers and a bit more documentation should make these features easy to use. Even now, they seem (on the Mac, at least) to work as advertised.
I’m happy to look a your project file if you attach it (no real data please). You can send it to charlesknightsbridge (at) gmail.com
Jamie
On Sep 13, 2014, at 4:18 PM, epidata-list@lists.umanitoba.ca wrote:
I have done that but during data entry it is not stoping on duplicate ID entry. At the end of last field entry it is not moving for second record.
Thanks, Rasool Bux
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.
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. Solution: after entry of each of the fields declared key, check to see if all the keys have been entered and then perform the check for uniqueness.
Jamie
On Sep 13, 2014, at 4:18 PM, epidata-list@lists.umanitoba.ca wrote:
I have done that but during data entry it is not stoping on duplicate ID entry. At the end of last field entry it is not moving for second record.
Thanks, Rasool Bux
epidata-list@lists.umanitoba.ca wrote:
All you have to do, is to define a key, which you find under project properties. After definition of a key, only one observation can be entered for each value.
In entryclient a key is always what was "key unique" in Classic Epidata 3.1.
Regards Jens Lauritsen
epidata-list@lists.umanitoba.ca skrev:
Dear all,
I have tried to use epidata manager & client. The Entry client is not indicating on duplicate entry of id field as in Epi data classic 3.1. Please let me know if there is any option to give message just after entering the key field and stop the entry to next fields.
Thanks & best regards, Rasool Bux
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. _______________________________________________ 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. _______________________________________________ EpiData-list mailing list EpiData-list@lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list
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.
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.
epidata-list@lists.umanitoba.ca
-
epidata-list＠lists.umanitoba.ca