Part of my point is that there are so many things interacting
here, that it's very hard to pin down what causes the Access
juggler to occasionally drop the ball.
Sure -- I agree with that, but I think solid development practice
includes frequent compiles and saves even when *not* working in
break mode. That's why I add the toolbar buttons to make it easy for
me to hit the compile every time it occurs to me.
I see the question "should I compile now?" as exactly the same as
"should I save my file now" or "should I backup my file now?" -- all
three of those question should never ever be answered with anything
but YES, YES, YES! If you're asking the question, you should JUST DO
IT.
Sounds like you have developed a work practice that you know works
reliably, whereas I'm often trying to work out what somebody did,
so intentionally NOT following a good work practice, so it's not
surprising if I experience corruptions more often than most.
It actually comes from my A97 practices. The major corruption
problems I had with interrelated standalone class modules happened
in A97, and I discovered that the problems came from the fact that
there were too many interrelationships between the
self-instantiating objects (I might consider never using the New
keyword with class module variables, and always instantiating them
explicitly when needed), and so I quickly learned that I needed to
compile and save after almost every code change.
That was also the project where I was weaned off supertype/subtype
table structures (a main table with 2 or more 1:1 child tables for
each subtype), because it was the problem of trying to manage those
that led me into the complex set of interrelated class modules (each
one representing each of the three subtypes in the app, but all
based on a class module based on the main type). It turned out to
be a disaster, both from the standpoint of managing the code, but
also in terms of performance (a list of all the items of the same
supertype had too many outer joins so that it was very slow; a UNION
ALL was better, and I didn't need editability for the list, but it
was still not fast enough; I concluded that the app likely should
have had a SQL Server back end).
Anyway, I digress....
The 'Compile on Demand' setting is another of those interacting
factors, and really important one. CrazyAccessProgrammer, make
sure that you have this option turned off. It is certainly a
factor. You may also get some help from David's suggestion of his
forcing of the compile/save.
I really think that the reason I don't encounter corruption is
entirely due to those two practices, which I follow religiously --
the COMPILE/SAVE process is just so ingrained into my working habits
that it happens without me even thinking about it.
Just as I decompile and compact regularly as part of the development
cycle, I think the COMPILE/SAVE reflex is crucial to maintaining
stability in the project.
And it has worked well for me.
At least, so far!