Repost: VBA bug ? Any Microsoft folks out there ?

[jfp]

This has just happened again ... hence the repost. This really looks
like a corruption issue of some sort, and it is getting to be a
nuisance! Can anyone help ?
-=-=-=-=
This has happened to me a few times (obviously, at random)

In Module A (typically a simple code module) i have a function X with an
arg declared as ByRef (and perhaps other arguments as well)
In Module B (typically a form module) i call X.

Everything compiles and works.
I save copies of A and B (via "File / Export File" from the VBA IDE).

Then, i make various changes to B. None of these affect the call to X.
I make NO changes to A. Sooner or later, when i compile, i get an error
in B at the function call to X, stating that there is a "ByRef argument
mismatch".

To fix this, i delete ALL the code from A and reload it (via "Insert /
File" from the VBA IDE) from the saved copy. Again, everything compiles
and works.

This is scary. Any comments ?
Access 2002 (10.2627.3311)
NO Service Packs installed.

P.S. This last time, the arg in question was a DAO.RecordSet. I do not
remember if it has been this way the other times, but it may well have
been.
-=-=
This time: I saved a clean copy of the database (compiled, ran ok)
I made some changes to module B (as above). No changes to A.
Same error. I saved the database at this point also. Then, I deleted
module A and imported A from the saved database. Compilation is now ok.
Since I have saved the database that failed, i could send it for
examination if desired.

 

[Brendan Reynolds \(MVP\)]

During intensive development of complex applications, I find this kind of
thing happens (very approximately) about once a week - a big improvement on
Access 2000, where it was much more frequent. When it happens, I usually
import everything into a new, empty MDB. Deleting the code and re-importing
it as you describe often fixes it too (or just copying the code, pasting it
into Notepad, closing and re-opening the MDB and pasting the code) but
subjectively (I've never kept any detailed records on this) importing
everything into a new MDB seems to be a longer-lasting solution. When I
replace just the problem code, the problem seems to re-occur sooner - but I
have to stress again that this is just a subjective impression.

I really should start keeping better records! :-(

The good news is that I've only ever seen it happen during development,
never while the app is in use. My understanding (from previous newsgroup
discussions) is that it happens when the compiled version of the code
somehow gets out of synch with the editable source code, which of course can
only happen when the source code is actually being changed.

 

[ben]

To echo Brendan, I too have seen this a lot, less in 2K,
but often in 97. Especially when there is a lot of code
in the application. Our solution has been to, as
mentioned, copy the code into notepad, delete the code
from the module and paste it back in. Having on occasion
used ctrl+X rather than ctrl+C, we have noticed that
there seem to be extra line breaks or hidden characters
lurking around. Don't know if that has anything to do
with the problem, interesting though. We've sort of taken
it as a fact of life that sometimes you have to do this.
We have never seen a problem in production with an .mde
(the application starts at about 90MB even). I'm sure
this is a 'known bug' in Access, and you might even be
able to find a KB article stating 'This behavior is by
design'. More than anything, I think you just have to
learn to live with it. I'd love it if someone could prove
me wrong here.

 

[jfp]

Thanks Ben and Brendan for convincing me that i am not going nuts.
Some interesting points to add:
1) This has continued to happen, always at the same line in the form.
The arg with the "byRef" mismatch is always an array of DAO.RecordSet.
(On earlier occasions, i believe it was a single DAO.RecordSet.) Could
this perhaps relate to the amibuity between DAO and ADO RecordSets ??
2) Fixing this has gotten to be rather routine as it always is in the
same place. Improving on your technique slightly, i: Ctl-A, Ctl-C,
Del, Ctl-V. That's seems to be sufficient -- no need to ever leave the
VBA environment.
3) Sort of related to this -- and i am not sure if this is me or MS:
When this happens, i notice several blank lines at the end of the code.
This seems to happen all over the place -- sort of like they grow there
and periodically need to be removed. Comments ?
-=-=-=