none
Overflow error 6 in Access 2007 not present in Access 2000

    Question

  • I converted an Access 2000 database to Access 2007.  I'm getting a  "Run time error #6 - Overflow" that I never got when running the VBA code in Access 2000.   Is it possible that Access 2007 can't handle code created in Access 2000.  Below is the pertinent code snipet:  The last line is the code that is getting rejected.

    DIM mFYESchg as long
    DIM mtotFYES as long
    DIM mtotFYESP as long

    mFYES = 1 + ((mtotFYES - mtotFYESP) / mtotFYESP

     

     

    Wednesday, February 02, 2011 8:33 PM

Answers

  • Well right away I see a missing paranthesis...

    mFYES = 1 + ((mtotFYES - mtotFYESP) / mtotFYESP)

    mFYES = 1 + ((mtotFYES - mtotFYESP))/ mtotFYESP

    ...not sure where you want it.  OR did you miscopy that line?


    --
    Gina Whipp
    Microsoft MVP (Access)

    Please post all replies to the forum where everyone can benefit.
    • Marked as answer by Bessie Zhao Thursday, February 10, 2011 9:45 AM
    Wednesday, February 02, 2011 10:24 PM
  • In addition to Gina's observation, I would suspect that you may have a divide by zero problem.  If mtotFYESP is ever zero, you will get an error.  In the past, I sometimes got an overflow error instead of a divide by zero error.

    IF mtotFYESP <> 0 THEN
       mFYES = 1 + ((mtotFYES - mtotFYESP) / mtotFYESP)
    Else
       ' Do nothing
       ' or return some other values
    END IF


    John Spencer Access MVP 2002-2005, 2007-2011 The Hilltop Institute University of Maryland Baltimore County
    • Marked as answer by Bessie Zhao Thursday, February 10, 2011 9:45 AM
    Thursday, February 03, 2011 2:23 PM
  • "lemarbe" wrote in message
    news:92c1dfd2-1da6-4ea9-ac4e-c46cffd0ae4e@communitybridge.codeplex.com...
    >I converted an Access 2000 database to Access 2007.  I'm getting a  "Run
    >time error #6 - Overflow" that I never got when running the VBA code in
    >Access 2000.   Is it possible that Access 2007 can't handle code created in
    >Access 2000.  Below is the pertinent code snipet:  The last line is the
    >code that is getting rejected.
    >
    > DIM mFYESchg as long
    > DIM mtotFYES as long
    > DIM mtotFYESP as long
    >
    > mFYES = 1 + ((mtotFYES - mtotFYESP) / mtotFYESP
    >
    >
     
    This can't be a copy/paste of the actual code, because the capitalization is
    all wrong, in addition to the unbalanced parenthesis that Gina pointed out.
    Please copy and paste the actual code, rather than retyping it.
     
    In general, there is no difference between the VBA in Access 2000 and the
    VBA in Access 2007.  There are some differences in the object model and the
    properties and methods of the objects, but the VBA language is still the
    same.  If code that ran under A2000 fails under A2007, and the code has
    really not been changed at all, then it's most likely that there's something
    different about the data.
     
     

    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html
    • Marked as answer by Bessie Zhao Thursday, February 10, 2011 9:45 AM
    Thursday, February 03, 2011 6:00 PM
  • lemarbe

    First, add Option Explicit to the top of the module then you will see where (like in the above snippet you posted) your variable declarations do not match your expressions.

    Start there, and when you have that all straightened out, see if you still get the error.


    Mark Burns, MCAD, MCP
    Sr. Microsoft Access Analyst/Developer
    Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN)
    • Marked as answer by Bessie Zhao Thursday, February 10, 2011 9:45 AM
    Friday, February 04, 2011 7:29 PM
  • DIM mFYESchg as long
    DIM mtotFYES as long
    DIM mtotFYESP as long

    mFYES = 1 + ((mtotFYES - mtotFYESP) / mtotFYESP

    As suggested please copy and paste the lines of code and the definition of mEYES.  Is it a variable or a property of some object.  If it is a property check the property definition to see if it is a integer and not a long.

    Also put the following immediately before the calculation line:
    Debug.Print mtotFYES, mtotFYESP, mtotFYESP

    Finally, please confirm that you are running Office 2010 32 bit not 64 bit.

    • Marked as answer by Bessie Zhao Thursday, February 10, 2011 9:45 AM
    Sunday, February 06, 2011 3:14 PM

All replies

  • Well right away I see a missing paranthesis...

    mFYES = 1 + ((mtotFYES - mtotFYESP) / mtotFYESP)

    mFYES = 1 + ((mtotFYES - mtotFYESP))/ mtotFYESP

    ...not sure where you want it.  OR did you miscopy that line?


    --
    Gina Whipp
    Microsoft MVP (Access)

    Please post all replies to the forum where everyone can benefit.
    • Marked as answer by Bessie Zhao Thursday, February 10, 2011 9:45 AM
    Wednesday, February 02, 2011 10:24 PM
  • In addition to Gina's observation, I would suspect that you may have a divide by zero problem.  If mtotFYESP is ever zero, you will get an error.  In the past, I sometimes got an overflow error instead of a divide by zero error.

    IF mtotFYESP <> 0 THEN
       mFYES = 1 + ((mtotFYES - mtotFYESP) / mtotFYESP)
    Else
       ' Do nothing
       ' or return some other values
    END IF


    John Spencer Access MVP 2002-2005, 2007-2011 The Hilltop Institute University of Maryland Baltimore County
    • Marked as answer by Bessie Zhao Thursday, February 10, 2011 9:45 AM
    Thursday, February 03, 2011 2:23 PM
  • "lemarbe" wrote in message
    news:92c1dfd2-1da6-4ea9-ac4e-c46cffd0ae4e@communitybridge.codeplex.com...
    >I converted an Access 2000 database to Access 2007.  I'm getting a  "Run
    >time error #6 - Overflow" that I never got when running the VBA code in
    >Access 2000.   Is it possible that Access 2007 can't handle code created in
    >Access 2000.  Below is the pertinent code snipet:  The last line is the
    >code that is getting rejected.
    >
    > DIM mFYESchg as long
    > DIM mtotFYES as long
    > DIM mtotFYESP as long
    >
    > mFYES = 1 + ((mtotFYES - mtotFYESP) / mtotFYESP
    >
    >
     
    This can't be a copy/paste of the actual code, because the capitalization is
    all wrong, in addition to the unbalanced parenthesis that Gina pointed out.
    Please copy and paste the actual code, rather than retyping it.
     
    In general, there is no difference between the VBA in Access 2000 and the
    VBA in Access 2007.  There are some differences in the object model and the
    properties and methods of the objects, but the VBA language is still the
    same.  If code that ran under A2000 fails under A2007, and the code has
    really not been changed at all, then it's most likely that there's something
    different about the data.
     
     

    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html
    • Marked as answer by Bessie Zhao Thursday, February 10, 2011 9:45 AM
    Thursday, February 03, 2011 6:00 PM
  • In general, there is no difference between the VBA in Access 2000 and the
    VBA in Access 2007.  There are some differences in the object model and the
    properties and methods of the objects, but the VBA language is still the
    same.  If code that ran under A2000 fails under A2007, and the code has
    really not been changed at all, then it's most likely that there's something
    different about the data.
     
     

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


    Dirk, while the above is true, it's only from the perspective of Access users (that's us !).
    You said that VBA had not changed. But there is no question that MSFT had to modify the VBA interpreter for 2007. There are new features to support like TempVars, etc. Also, there was all of that "switch" code to handle MDB vs. ACCDB formats. That was significant IMHO.

    So the question is this: what OTHER mods were done when the Access programmers made the changes to support 2007 ? In other words, how many "WTFs" were spotted and fixed.

    I had discussed this very issue in an earlier post. The issue is always the same: software companies don't like to air their "dirty laundry" i.e. "bugs". They find them, and then fix them....silently. I don't disagree with this philosophy. However, it does leave us susceptible to some changes in behavior for each new release that have no apparent explanation and more importantly....no documentation.

    Friday, February 04, 2011 2:19 PM
  • change 1 to 1.0000000001

     

    Greg

    Friday, February 04, 2011 4:38 PM
  • "Syswizard" wrote in message
    news:0e5d0e74-c9d2-4ae7-b045-d18a3bd2e5b8@communitybridge.codeplex.com...
    >
    > Dirk, while the above is true, it's only from the perspective of Access
    > users (that's us !).
    > You said that VBA had not changed. But there is no question that MSFT had
    > to modify the VBA interpreter for 2007. There are new features to support
    > like TempVars, etc. Also, there was all of that "switch" code to handle
    > MDB vs. ACCDB formats. That was significant IMHO.
     
    However, those things you mention were not changes to VBA itself.  They were
    changes to various of the object models used by Access -- in particular, the
    Access object model (for TempVars) and the DAO object model (for muti-valued
    fields and other such features that came with the new Access Data Engine).
     
    Nevertheless, the VBA interpreter itself is unchanged between Access 2003
    and Access 2007.  If you go into the VB Editor environment and click on
    Help -> About Microsoft Visual Basic..., you'll find that it reports the
    same version for both Access 2003 and Access 2007:  Microsoft Visual Basic
    6.5.  In my case, at least, they both even report the same subversion, 1053.
    I suppose, of course that the application of a service pack or hotfix may
    cause the subversion to be different, but I get the same result on two
    different computers, one with A2003 and one with A2007.
     
    Now, when I open up Access 2010, I get a different version of VBA -- version
    7.0.  I don't know what changed in VBA between Access 2007 and 2010, but
    it's clear that these are different versions of VBA, and there could be some
    different behavior.  That said, I would be *extremely* surprised to find
    that there is a difference in the handling of the little snippet of code
    that was posted.  The behavior of variable declarations and implicit
    type-casting in expressions is too well defined in the language standard,
    and a lot of existing code would break if it were changed.
     
    > I had discussed this very issue in an earlier post. The issue is always
    > the same: software companies don't like to air their "dirty laundry" i.e.
    > "bugs". They find them, and then fix them....silently. I don't disagree
    > with this philosophy. However, it does leave us susceptible to some
    > changes in behavior for each new release that have no apparent explanation
    > and more importantly....no documentation.
    >
     
    If only they would fix the old, known bugs, rather than just the ones they
    create while introducing new features.
     
     

    Dirk Goldgar, MS Access MVP
    Access tips: www.datagnostics.com/tips.html
    Friday, February 04, 2011 5:46 PM
  • lemarbe

    First, add Option Explicit to the top of the module then you will see where (like in the above snippet you posted) your variable declarations do not match your expressions.

    Start there, and when you have that all straightened out, see if you still get the error.


    Mark Burns, MCAD, MCP
    Sr. Microsoft Access Analyst/Developer
    Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN)
    • Marked as answer by Bessie Zhao Thursday, February 10, 2011 9:45 AM
    Friday, February 04, 2011 7:29 PM
  • DIM mFYESchg as long
    DIM mtotFYES as long
    DIM mtotFYESP as long

    mFYES = 1 + ((mtotFYES - mtotFYESP) / mtotFYESP

    As suggested please copy and paste the lines of code and the definition of mEYES.  Is it a variable or a property of some object.  If it is a property check the property definition to see if it is a integer and not a long.

    Also put the following immediately before the calculation line:
    Debug.Print mtotFYES, mtotFYESP, mtotFYESP

    Finally, please confirm that you are running Office 2010 32 bit not 64 bit.

    • Marked as answer by Bessie Zhao Thursday, February 10, 2011 9:45 AM
    Sunday, February 06, 2011 3:14 PM