How can I prevent the input mask problem while copying the row? (1 Viewer)

SORM2

New member
Local time
Today, 15:53
Joined
Jan 16, 2021
Messages
25
Hi everyone,

I have a tabular form which has input mask for date fields "00.00.0000". So when the user wants the copy the record and paste as new record, it is generating error if these date fields have the value like 9.03.2020 because day area is only one integer while the input mask was two.

İs there a way to prevent this copying mistake? If the first integer which is zero remains like that, 09.03.2020 after manual entry, then actually this problem will be eliminated. However I could not find a way to achieve that. Or maybe there can be other solutions as well.

Thanks
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 13:53
Joined
Sep 12, 2006
Messages
14,640
If the input mask has a leading zero, how does the data not also have a leading zero?
Are you copying from excel, or something like that?
 

SORM2

New member
Local time
Today, 15:53
Joined
Jan 16, 2021
Messages
25
If the input mask has a leading zero, how does the data not also have a leading zero?
Are you copying from excel, or something like that?
Hello when you wirte the date like 09.03.2021, after this row took an PK id (saved in database), then it is automatically be converted into form 9.03.2021.
Therefore when you want to copy and paste it to second row, it does not accept in this time because of the input mask.
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 13:53
Joined
Sep 12, 2006
Messages
14,640
I see. I missed the fact that the number represented a date.

In my opinion in general, If you want a leading zero, then you ought to use a string, not a numeric. If the leading zero is significant, then you have a string, not a number. So a phone number is really a string, not a number. Given that a "long" is max 2 billion approx, you can't store most phone numbers as numbers using a long, and you never manipulate a phone number as a number anyway.

Now a date is different again. A date should actually be stored as a date, and then you wouldn't have an issue, but you would end up with 09/03/2021. Access will reject invalid dates. Access will also auto-correct your dates. If you enter 9/3/21, or even just 9/3, Access will insert the current century/year, and then you don't actually need the formatting at all. The date itself is stored as a real number, and could be used as a PK, providing you don't want duplicates. eg In your case you could legally enter 31.04.2021 which is not a legal date, but presumably would be accepted in your format. Access/VBA comes with loads of assistance for manipulating dates.
 

Users who are viewing this thread

Top Bottom