>>Our team appreciates any thoughts you may have to offer concerning such a well documented error <g>. Thanks, Microsoft...
>>
>This is an independent forum. Any replies will probably not come from a MS representative. Although they do routinely visit this forum.

Mark... Er, I'm pretty sure he was being sarcastic. Because one suspects that in fact Scott does not believe the error to be "well documented." All jest aside... Scott: A couple other things to try that probably won't help.

- Open all the classes as tables and pack them.
- Recompile all classes: COMPILE CLASS xxx
- Dump the data environment if you are using it and load tables in your load code. (Use a specialized loading program so you can globally change you error trapping in this.)

If that doesn't work, which it probably won't but is good practice anyway, you can do some miserably rigorous debugging. You've done so much work already trying to find the bug that it might not seem ridiculous to call a method m_recordLine between every line in the Load and Init methods which saves the current line number to a MEM file. Then when you crash you know where you crashed. (This is assuming that the crashes are pretty infrequent. Otherwise you could just try to cut the ambiguity of location in half for each failure.)

Best Luck,
Adam