MM/YYYY edit mask

[mcnewsxp]

anyone know of a way to get an edit mask that allows and stores a valid date
in MM/YYYY format.
if not a valid date then at least prompts the user to enter data in MM/YYYY
format.
BTW - 99/9999;0; does not do it.
thanks much.
mcnewsxp

 

[Guest]

Format is how data is presented. Especially with dates, it has little to do
with how data is stored. In fact the date 06/30/2006 is stored as 38898 in
Access.

Debug.Print CDbl(#06/30/2006#) = 38898
or for date and time
Debug.Print CDbl(#06/30/2006 1PM#) = 38898.5416666667

So you use a format to display just the month and year.

Below is an input mask that should just allow the month and year to be
inputted:
99/0000;0;_

You will still need to use your format to show just the month and year in
forms, reports, and queries or the 1st day of the month might show up.

 

[Steve Schapel]

mcnewsxp,

Whereas I agree with Jerry's advice specific to your question, I have a
question about the Data Type of the field. Apparently you are using a
Date/Time field. Is that the correct decision? I'm not sure, because
we haven't got enough information about what you are using this for, and
how you are using it. It's not enough to say that you can see this sort
of information on a calendar, and therefore it's Date. In a database,
these decisions are based on the required functionality. So here's how
I would read it... you want the month and the year, it doesn't matter
about the day, means it is very likely that you do not want date
functionality. So yes, it is possible to shove it into a Date/Time
field, using techniques such as input mask as discussed in this thread.
But the question still looms - why? A valid date requires all three
components - day, month, year. Unless there's something I don't know
yet about your database to make me change my mind, at the moment it
looks to me that you don't want a date, you want a month and year. As
such, I wouldn't use a Date/Time data type field. I would either use 2
separate Number fields, one for month and one for year, or else I would
use a text field to store like 07/2006. My decision between these two
options would depend on how I wanted to use the information, but I
really don't think it's a date.