The sample db demonstrates incorporation of suitable safeguards, taking into 
account certain peculiar features associated with input masks for date type 
controls, as detailed below.
    (a) - Mask violation (e.g. skipping of a digit that is mandatory as per mask) is 
          trapped in form's error event through DataErr 2279. 
    (b) - Date violation (i.e. a string that can not be interpreted as a valid date, even 
          by juggling all possible combinations of day/month/year parts) is trapped in 
          form's error event through DataErr 2113. This error has nothing to do with 
          input mask and gets triggered for invalid date even when there is no mask.
    (c) - Above error values are not to be confused with conventional error. Even 
           when DataErr 2279 or 2113 gets precipitated, the value returned by 
           Err.Number remains zero.
    (d) - DataErr 2279 takes precedence over 2113.
    (e) - When either of DataErr 2279 or 2113 is encountered, control's 
           BeforeUpdate event does not get a chance to fire.
    (f) - Input mask for date type control must have zero as its second argument 
          (i.e. just after the first semicolon). Otherwise, it will attract DataErr 2113 even 
          for a valid date. For example, use 00\-00\-0000;0;_ instead of 
          00\-00\-0000;;_
    (g) - Absence of any error (2279 or 2113) is no guarantee that the date value is 
           going to be as intended by the format in force. For example an entry 22-04-
           2005 would get stored as 22-Apr-2005, even when the format for data entry 
           is mm-dd-yyyy. Such anomalies need to be trapped through a super-check in 
           control's BeforeUpdate event.
    (h) - If the format for data entry is in conflict with that for regional setting for short 
           date on the particular computer, there is another pitfall. The value as 
           entered, even though free of any error and despite being found valid as per 
           intended format (via super-check in control's BeforeUpdate event), would 
           still get  interpreted and stored as per the local system settings on the 
           computer (unless the day part is greater than 12 and can not be interpreted 
           as month part). For example, if the format for data entry is mm-dd-yyyy, while 
           the system setting for short date is dd-mm-yyyy, 07-04-2005 will get stored as 
           07-Apr-2005 (instead of 04-Jul-2005). Remedial action becomes necessary 
           in control's AfterUpdate event.
    (i) - On entering a date type control for editing existing data, its format property, if 
           in conflict with the system setting of format for short date, gets over-ruled by 
           the latter. On exiting the control, the format property specified for it governs 
           data display (even if in conflict with the system setting).

Download : http://www.rogersaccesslibrary.com/forum/uploads/37/InputMaskDateValidation.zip - uploads/37/InputMaskDateValidation.zip