Thank you very much for this workaround! This is exactly what I need. It worked fine after adding an extra 'endif' and 'end' to field2. Peter.
epidata-list@lists.umanitoba.ca wrote:
Peter,
I get the same result. The problem also arises with a <yyyy/mm/dd> date field. The problem is worse with this format as illegal dates get stored in the .rec and then are unusable. This is a bug in the parsing of dates, as any date with extra digits in either part should be caught. I'll add an entry to the documentation system.
If you have a challenging data entry situation, you could separate day, month, year into three fields and apply the checks separately. Here is a way to do that. An invalid date is always caught, either by the individual ranges or by the date function under field2. Field1 and Field2 are created when the "first word" option is chosen for creating .rec files. Error checking during data entry can be turned off, but the error in coding dates will always show up and the user is forced to fix things (e.g. 29 02 2009)
dobs ##/##/#### (day, month, year) dob <dd/mm/yyyy> (confirm date)
dobs range 1 31 end
field1 range 1 12 end
field2 range 1900 2010 after entry dob = date(dobs,field1,field2) if (dob > today) then help "Date @dob is out of range" error clear dob goto dobs end
dob noenter end
Jamie