Thanks. I think what was making me think it was working is that we use the same code for composing "problem" messages (i.e., things we trap in code).

The specific issue is that some set of processing is being performed (data is being extracted from some text files and entered into a database) and an error occurs. The base class has code in its Error method which gathers the error number, program line, object name, method affected, etc. and passes these as parameters to goErrorMsg.SetError. goErrorMsg is a global object created in the main program, visible to everyone.

The SetError method wants to look up a composed error message corresponding to the error number in an ErrorMessages table; it will take that message and "merge" the parameters into it to create the resulting human-readable message.

However, life and computers being the way they are, we want to protect goErrorMsg from any possible problems with the table (which is a free table used by several programs, installed in a fixed location). It might be missing, or the table corrupted, or the memo file missing, or the table locked somehow.

So we added an Error method to goErrorMsg to (supposedly) trap any errors that happened inside...setting a private property .pMyError

And so, when we need the message table, we do

Use (.ErrorTable) IN 0 Shared
If .pMyErrorNo <> 0
Return a message with as much information as possible
about the error and the problem in the error message object
Else
Go ahead and compose and format the message
EndIf

This will clearly not work in this case... I can obviously use File() to check for the existence of the table files, and that will cover the most likely scenarios. There are some additional workarounds we can use short term...but are there any ways to check on the status of the memo file, lock status, all the other reasons USE wouldn't work? Long term, we could put the content into a text file or something, but we need to ensure that we don't get unanticipated error messages popping up, as the same messaging object may be used as part of COM objects in the future.

Thanks much,
Bruce