Re: Mystery Access VB bug

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Allen Browne (AllenBrowne_at_SeeSig.Invalid)
Date: 09/08/04 

Date: Wed, 8 Sep 2004 18:12:31 +0800

Hi Sam

I hope you get several replies, as this kind of thing is hard to diagnose.

>From your description, it sounds like your mdb is becoming partially
corrupt. The fact that the problem can be fixed by replacing the code with
identical code reinforces that view.

Access keeps 2 copies of your code: the text version (what you edit), and
the compiled version (what actually runs). While you are modifying forms and
their modules, it is quite common for Access to get these two out of sync,
and you then have a corruption.

IME, one of the things that triggers this corruption is editing the module
of a form in break mode. That is, you open a form (not design view). An
event is triggered. Your code runs, and hits a bug. You choose to Debug, and
are dropped into the VBA window with the problem line highlighted. At this
point, if you edit the code, Access has to create a temporary copy of the
form and the code (as it always does when you start an edit) so that it can
revert to the previous saved state if needed. So, it is now trying to juggle
four copies of the code: text and compiled of original and temporary, and
some of these are being created while some are running. Somewhere in this
process, it gets the copies confused.

Occassionally you can actually catch it out: even though you have altered
the text version of the code visible in your editing window, the Compile
option on the Debug window sometimes remains greyed out (assuming you were
fully compiled at this point), i.e. Access still thinks the project is
compiled, even when you have altered the code. Another indication is that it
can zip straight past a breakpoint without stopping. The compiled version it
is using is out of sync with the text version.

Once we realized what was going on, we made a conscious decision never to
edit in break mode, but to always switch the form to design view before
editing the module of the form. This was in Access 97, and our corruptions
during development dropped dramatically.

For other suggestions on preventint corruption, see:
    http://members.iinet.net.au/~allenbrowne/ser-25.html
#2 and #3 do not apply to Access 97, but the other ideas may help. 

-- 
Allen Browne - Microsoft MVP.  Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"Sam Smith" <sam@itsoftworksnospam.com> wrote in message
news:7e1601c49586$7ea14130$a601280a@phx.gbl...
>I wonder if I am going insane. Across all recent versions
> of Access I seem to have come across the following bug and
> I just thought I would mention it to see if there is any
> interest from MS to actually fix it.
>
> The weird bug:
>
> Every so often in forms coding I eventually get to a point
> where I get an error in the same way as if I had a missing
> reference but it has, in fact, nothing to do with that at
> all except appears to be some sort of mystery internal
> Access bug. The latest occurrence of this bug in detail:
>
> I have a form with a sub form. On the event on one of the
> text boxes in the sub form I have some simple code which
> activates when the text box is double-clicked.
>
> This is all working fine until the mystery internal bug
> appears.
>
> In changing some code I decide to make one variable
> public. This then seems to break the double-click code. If
> I remove the new variable and put the code back to how it
> was the bug is still there. Every time I double click on
> the text box in the subform I get the usual error that I
> would get if I had a missing reference.
>
> But it gets weirder (and more annoying).
>
> If I import over the SAME CODE (identical in everyway)
> from a backup - it works fine. If I try to run the old
> code then it brings up the reference error. 2 pieces of
> code that are identical to the Access developer but
> internally must look different to Access.
>
> Now, there is obviously a lot going on behind the scenes
> in Access that us developers are not privy to and it is
> clearly that something in the internal code of Access
> itself is screwy. I have used Access since '97 and have
> come across this weird reference bug in different guises
> off and on since then. It doesn't happen very often -
> perhaps once every 6 months. I do use Access every day so
> perhaps only a few of us will trigger this.
>
> Although I keep getting around it I just thought that it
> might be nice if MS could be made aware of it and release
> a patch - because when it occurs it is a real pain to
> debug as it is not actually anything a normal developer
> can fix as it is internal to Access.
>
> If this could be fixed then it would make Access even more
> perfect! :)
>
> ---
> Sam

Relevant Pages

  • Re: Release vs. Debug builds...
    ... If we compile the application on MY ... instance of the anti-virus software corrupting the input file. ... the corruption added data that simply prevented the file from ... but with a bug in it somewhere. ...
    (microsoft.public.win32.programmer.directx.video)
  • Re: PROBLEM: memory corrupting bug, bisected to 6dda9d55
    ... It's corruption of user memory, ... there was a pre-existing bug which 6dda9d55bf545013597 has exposed - ... so I could apply the patch to just one of them. ...
    (Linux-Kernel)
  • Re: No crrent record with empty subform
    ... records to display, sometimes not. ... And as I mentioned earlier, I even get the error when clicking the form over to design view, when the subform does not happen to be displaying any records. ... Compile menu item while the form is in design view. ... code corruption is when you edit the code while the ...
    (microsoft.public.access.formscoding)
  • Re: Pedants
    ... it was a genuine bug. ... no reason to assume that gcc-specific headers will compile with any ... If some gcc-specific header didn't compile with gcc, ... general container library for instance. ...
    (comp.lang.c)
  • Re: automated test? (was Re: Linux 2.6.17.7)
    ... a bug report may not convey the hint "look at this NOW, ... what I was intending with my origional question was a series of simple 'does it compile' tests that try all the config options that are affected by the patchset in question. ... obviously such a test can't be done on the huge -rc patches, but for -stable patches ... Given a patch that modifies file X is it possible to know what config options could be affected? ...
    (Linux-Kernel)