none
Date field /data corruption bug in MS Access runtime 2010 SP2 RRS feed

  • Question

  • I have found a bug whereby a user typing into a date field using a day number that is too high for a given month gets the month changed by the UI without any warning or other user feedback to make them aware of the change

    For example typing '31/11/2016' gets the date automatically changed to '31/12/2016' because there is no 31st day in November.  Correct behaviour would have been to prompt the user to supply a correct date, or at the very least, any auto correct for day numbers that are too high in a date should be prompted, and default to the highest correct day in the month (in this case 30/11/2016) - not change month altogether.

    Unless the user is lucky enough to notice the change at the time, any reports generated using this auto changed date will include a whole month's extra data.

    In my case this actually happened, costing me thousands of dollars in overpaid tax.

    There is no way for any 3rd party application developer to deal with this, as the date input is changed by Microsoft before the developer logic is run.  

    How can we get Microsoft to fix this?

    Wednesday, January 31, 2018 12:07 AM

All replies

  • For what it's worth, I can't reproduce this with a full installation of Access 2010 SP2.  Entering 11/31/2016 or 31/11/2016 in a date field causes Access to display an error dialog, and it requires me to fix the invalid entry.  I'm sorry, but I don't have a copy of the runtime version installed to test with. 

    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html

    Wednesday, January 31, 2018 4:03 AM
  • I have NEVER seen this behavior and I agree if it happened to me I would be unhappy to say the least. Can you post a sample database with this problem in a public place, like a free OneDrive account?

    Is this perhaps a situation of non-US dates? IOW, are you in the US using US database and US keyboard and US Windows and US language settings?


    -Tom. Microsoft Access MVP

    Wednesday, January 31, 2018 4:26 AM
  • @Dirk: you could simulate the Runtine with /runtime, but I am sure that would not make any difference.

    -Tom. Microsoft Access MVP

    Wednesday, January 31, 2018 4:28 AM
  • Even with the /runtime switch, it gives the same result.

    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html

    Wednesday, January 31, 2018 4:39 AM
  • Yes, this is a situation with non US date format.  Using international/English date format dd-mm-yy

    I am using a US keyboard & US windows 10 with English (New Zealand) language & region settings

    I am an end user rather than developer, but the 3rd party software using the access runtime is available for free (90 day trial) here http://www.cashbookcomplete.com

    I am reluctant to post my own database, as it contains personal financial data, but it is easy to create another one using this software.  There is a setup wizard in which region and date settings are queried.

    To reproduce (assuming you have set dd/mm/yyyy as your date format in the wizard),  click on the menu Cashbook/Print GST return, and a dialog will pop up prompting you for start and end dates.

    Simply type in 31/11/2016 as a date, and you will see the month figure automatically changing.

    The developer has advised the problem inherently lies with the runtime, and is not something they can fix, and that I should try reporting it to Microsoft.  Hoping someone here in a position to do that will be able to replicate the issue

    Thursday, February 1, 2018 10:16 AM

  • The developer has advised the problem inherently lies with the runtime, and is not something they can fix............

    As the late lamented Mandy Rice Davies famously said:  "He would, wouldn't he?"



    Ken Sheridan, Stafford, England

    Thursday, February 1, 2018 11:25 AM
  • Yeah me too:

    <skeptic level="high'>


    -Tom. Microsoft Access MVP

    Thursday, February 1, 2018 1:52 PM
  • The developer has advised the problem inherently lies with the runtime, and is not something they can fix, and that I should try reporting it to Microsoft.  Hoping someone here in a position to do that will be able to replicate the issue

    Do you have any reason other than the developer's assertion to believe that the problem is with the runtime?  It has always been my understanding that the runtime is just the regular MS Access with most of the built-in user interface elements disabled, and yet the behavior can't be reproduced in non-runtime.

    If I enter 11/31/2016 or 31/11/2016 in a date field on a form, error 2113 is raised.  I can write error-handling code to trap that error and respond to it, but even if my error-handling code says "ignore that and continue", Access won't allow me to move on from the field until the invalid value has been corrected.  That's true even when I run the database in runtime mode.  My error-handling code *could* take its own action to correct the invalid entry, and that action *could* be incorrect.


    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html

    Thursday, February 1, 2018 2:00 PM

  • Do you have any reason other than the developer's assertion to believe that the problem is with the runtime?  It has always been my understanding that the runtime is just the regular MS Access with most of the built-in user interface elements disabled, and yet the behavior can't be reproduced in non-runtime.

    If I enter 11/31/2016 or 31/11/2016 in a date field on a form, error 2113 is raised.  I can write error-handling code to trap that error and respond to it, but even if my error-handling code says "ignore that and continue", Access won't allow me to move on from the field until the invalid value has been corrected.  That's true even when I run the database in runtime mode.  My error-handling code *could* take its own action to correct the invalid entry, and that action *could* be incorrect.


    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html

    Thank you for looking into it, and I have only the developers assertion to go on that:

    "We had a look at the problem your reported.  We do have the ability to check and modify/correct data after it is entered.  In this case however the date is automatically changed by MS Access from "31/11/2016" to "31/12/2016" before our logic is run.  Our logic just sees that "31/12/2016" has been entered.  If you want to get this fixed you need to talk to Microsoft because it is not anything we have any control over."


    • Edited by ArchPrime Thursday, February 1, 2018 3:00 PM font size issue
    Thursday, February 1, 2018 2:58 PM
  • Where in this application did you enter a date that was improperly adjusted?  I downloaded and installed the app in a virtual machine, so it is executing with the runtime, and so far when I enter a date with 31 days in November -- entered as 11/31/2017 or as 31/11/2017 -- it has not accepted it, but instead has simply cleared it without showing any error message.  I suppose it may happen in one place, but not in another, so it would help to know how to reproduce it.

    The version I installed was 6.30, configured for the Home version .


    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html

    Thursday, February 1, 2018 6:09 PM
  • Where in this application did you enter a date that was improperly adjusted?  I downloaded and installed the app in a virtual machine, so it is executing with the runtime, and so far when I enter a date with 31 days in November -- entered as 11/31/2017 or as 31/11/2017 -- it has not accepted it, but instead has simply cleared it without showing any error message.  I suppose it may happen in one place, but not in another, so it would help to know how to reproduce it.

    The version I installed was 6.30, configured for the Home version .


    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html

    Hi Dirk

    I can replicate the issue in a number of the dialogs that pop up from the various reporting options under the 'Cashbook' menu. For example the 'Print Summary Report' option behaves this way when a wrong date is entered.

    Interestingly I found there are some date fields in other dialogs that do not behave that way, and do correctly report when the date is in error.

    The issue seems to be confined to dialogs in which the date field has forward and back arrows for skipping forwards or backwards a month at a time.  If the user enters the last day of a month, then skips months forwards or backwards using the arrows, the day number automatically adjusts to the last day of each given month. 

    Perhaps whatever function enables these arrows and intercepts and modifies user input before it is entered is the culprit?


    Friday, February 2, 2018 12:17 AM
  • I can replicate the issue in a number of the dialogs that pop up from the various reporting options under the 'Cashbook' menu. For example the 'Print Summary Report' option behaves this way when a wrong date is entered.

    I get an unexpected result in that dialog, but interestingly, not the behavior that you reported.  If I enter an invalid date in that field, whether it is 11/31/2016 or 2/30/2018, it changes to 1/1/2018.

    The issue seems to be confined to dialogs in which the date field has forward and back arrows for skipping forwards or backwards a month at a time.  If the user enters the last day of a month, then skips months forwards or backwards using the arrows, the day number automatically adjusts to the last day of each given month. 

    Perhaps whatever function enables these arrows and intercepts and modifies user input before it is entered is the culprit?

    I assure you, this behavior is the result of something the developer has coded.  It is not due to Access, runtime or no.


    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html

    Friday, February 2, 2018 2:59 AM
  • Thanks Dirk, I have gone back to the developer with that info.

    Cheers

    Friday, February 2, 2018 7:23 AM
  • Thanks Dirk, I have gone back to the developer with that info.

    Cheers

    Further to this, with the benefit of your responses, the developer has found and fixed the problem - so appreciate your help Dirk, and all others who replied!
    Monday, February 19, 2018 12:20 AM
  • Further to this, with the benefit of your responses, the developer has found and fixed the problem - so appreciate your help Dirk, and all others who replied!

    Well, that is good news!  You're welcome.  I'm sure we were all glad to have helped -- and in doing so, defended Access against that false accusation. <g>


    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html

    Monday, February 19, 2018 12:30 AM