While a solution that flags dates as invalid/missing will be useful, another strategy for dealing with the invalid dates is to import them as text and use the built-in functions to convert valid ones to dates. There is still a potential problem with finding the invalid date records, but you have an opportunity to do this on your own terms.

I assume that the dates were imported somehow into a .rec file, as entry would not allow such dates. I don't recall whether import checks date validity, but it does other field types. The invalid dates can readily be checked using the validation capacity of EpiData Entry and .chk files. This may be the best way to do this, as a detailed report of errors is produced.

I have run into this type of error importing EpiInfo files and reading .dbf files, but not working with .rec files that I had control over.

Jamie

I have several concerns about this approach.

1. Most important, records with 'invalid' dates are excluded from

analysis (10 in this example). The fact that the 'invalid' dates are likely to be incorrect is no reason to not be able to analyse the records. 2. READing a large dataset with many dates can be a very slow process. 3. The output given by Analysis (as shown above) is not very useful. Neither record numbers nor variable names are identified.

I would like to suggest: a. That dates are not checked at all during the READ process. The analyst can look for incorrect dates in Analysis, relevant to the content of the data. OR b. That the user can specify whether to check the dates or not on READing a dataset. OR c. That, if neither a. nor b. is an option, more detail about the 'invalid' dates (record number, variable name) is provided so that they can be edited.

Annemieke van Middelkoop Pretoria, South Africa