>>That certainly is a strange behavior I've never encountered, but it's possible you can beat the problem with something along the lines of my approach error handling. I realized that you may not be in a position to do a major rewrite, and I'm not sure how much of a change would be required, however the basic idea may be applicable.
>>
>>Maybe you could adjust your error handler logic to capture the necessary info and set a flag, but let it return to the routine that encountered the error. Then let the logic of your method or function that does the COUNT immediately follow that step with a check to see if there was an error. If so, perform the appropriate context-specific error reporting, logging, abort, or whatever.
>>
>>You can take a look at my ErrHandler forum at http://www.ideaxchg.com/ix07/er/_sys/toccontu.htm, where you'll find documentation and a downloadable demo, with source code.
>
>It's not only in our application. It's also from the command window. We have that all the way. If the count is using an expression which contains a field that does not exist or an expression which contains a variable that doesn't exist, we will have that behavior.

Michel,

Be that as it may, it's still possible that my approach would circumvent the problem. If an Error event is triggered at all, you shouldn't need to depend on a non-local RETURN TO ... in this situation. A normal return from the Error handler to the offending code would suffice. Then you can invoke the appropriate context-specific error handling logic in normal code, after the Error handler is off the stack. The only time I use RETURN TO ... is for special cases of unanticipated errors, or if the user deliberately requests an Abort.

Mike