Andy wrote:
It's just every few weeks we get the files into a state where the functions just aren't getting called.
I'm fairly sure this is a bug in Excel 2007's dependency checking, as I've written a C# command line utility to fix it that basically does the following:
[....]
The call to CalculateFullRebuild fixes it (which further confirms that there's nothing wrong with the actual functions):
You may be correct. I have had similar experiences.
However, at least in some cases, the root cause of the pervasive and bogus "errors" from UDFs is that Excel seems to abort the recalculation process due to some unrelated error.
It is as if the recalculation engine initially marks all UDFs as returning a #VALUE (or #NAME) error by default. Normally, that is "fixed" when the UDF is eventually called during the recalculation cycle. But if Excel aborts the recalculation process before
that happens, the #VALUE (or #NAME) error sticks.
In that case, CalculateFullRebuild might remedy the problem simply because it reorders the recalculation.
So, some questions come to mind.
- After you use CalculateFullRebuild, are there Excel errors in some other cells, perhaps errors that you tolerate by design?
- Do you have any unintended circular references?
- Do you enable Iterative calculation, and do you have purposeful any purposeful circular references, particularly systems of non-self-referential CRs?
- Does the UDF reference other cells, thereby implicitly relying on a particular order of recalculation?
#4 is significant because Excel (2003 at least) recalculates some formulas multiple times, causing UDFs in those formulas to be be called multiple times, sometimes before implicit dependencies are met. This can cause some UDFs to misbehave if their design
does not tolerate these premature calls.
#3 is significant because I have seen instances where systems of non-self-referential circular references confuses the recalculation engine.