forcing 3-digit id numbers
I am using a unique ID for individuals in a study. The ID must be between 001 and 150 and it is a 3-character string field to ensure 054 is entered, for instance, rather than 54. Certain numbers can be entered with fewer than 3 digits without generating an error message. Without trying every possible combination, it seems that these numbers are 1, 10, 11, 12, 13, 14 and 15. The thing that these seven numbers have in common is that they could all be extended to 3 digits by filling in only zeroes, and still meet the criteria for the field (100, 100 again, 110, 120, 130, 140, 150). 160 is too big for the range, so 16 generates an error message. 200 is too big, so 2 is not allowed. This is just a guess to explain why these seven numbers slip through the filter. If I'm right, is there anything I can do about it? If I'm wrong, what's the explanation? Thanks for your help, Vicky Simms
King's College London
Vicky:
I reproduced your problem, and while perhaps awkward, this seems to be a possible solution:
Make an IDN as a numeric field and your ID as a text field:
QES:
idn ### id ___ sex #
In the CHK file you write:
idn RANGE 1 150 MUSTENTER AFTER ENTRY id=idn IF idn<10 THEN id="00"+id ENDIF IF (idn>9) and (idn<100) THEN id="0"+id ENDIF END END
id KEY UNIQUE 1 NOENTER END
and you have your ID as unique identifier in the format you want it to be.
Regards,
Hans
epidata-list@lists.umanitoba.ca wrote:
<div class="moz-text-flowed" style="font-family: -moz-fixed">I am using a unique ID for individuals in a study. The ID must be between 001 and 150 and it is a 3-character string field to ensure 054 is entered, for instance, rather than 54. Certain numbers can be entered with fewer than 3 digits without generating an error message. Without trying every possible combination, it seems that these numbers are 1, 10, 11, 12, 13, 14 and 15. The thing that these seven numbers have in common is that they could all be extended to 3 digits by filling in only zeroes, and still meet the criteria for the field (100, 100 again, 110, 120, 130, 140, 150). 160 is too big for the range, so 16 generates an error message. 200 is too big, so 2 is not allowed. This is just a guess to explain why these seven numbers slip through the filter. If I'm right, is there anything I can do about it? If I'm wrong, what's the explanation? Thanks for your help, Vicky Simms
King's College London
</div>
Vicky,
The reason Hans' solution is the best way to go is that range checking on strings is not a good way to check for numbers. For example, with
uid RANGE 000 150 END
entries like 10x will pass, since the string "10x" lies between "109" and "110", as do many, many other possible wrong entries. So RANGE will be quite happy.
If you want to force entry of 3 digits as strings, then it is best to enter them as single digits and check the range of each one, AND THEN, check the range of the resulting number. Basically, you are having to do what EpiData does for you whenever you enter an integer.
The .chk code isn't that difficult - let me know if you want to do it that way and I will post it.
Jamie
Vicky wrote:
The ID must be between 001 and 150 and it is a 3-character string field to ensure 054 is entered, for instance, rather than 54.
participants (1)
-
epidata-list＠lists.umanitoba.ca