>>This is a follow-up to the thread Error Record out of Range.
>>
>>I think Christian Isberner correctly wrote that the error possibly is triggered by either Clear Events or Quit or Cancel. But how do I log the problem is not clear.
>>
>>First, please confirm that I understand the sequence of events correctly. The program issues READ EVENTS at the top.
>>Then, whenever the program calls CLEAR EVENTS, the code goes to the first line after READ EVENTS. Correct?
>>
>>Then, how do I log, after READ EVENTS, that a problem occurred? Or how do I log, before READ EVENTS, that the problem was caused by CLEAR EVENTS?
>
>
>A 'record out of range' is not always trappable on a specific line. The first thing to do it to have a TRY CATCH around your READ EVENTS and use ASTACKINFO to capture information about where it occurs. In our case we have identified the error is sometimes trapped in the READ EVENTS line itself and therefore not caused by a specific line, but rather related to a cascade of firing events.
>
>In most cases we could track the cause back to grids. If you are using grids to enter data, it is possible that code in a valid event causing the record pointer to change causes the issue.
>Another notorious one is the use of indexes with grids where you enter data, especially in the column where the index is based upon.
>
>Any code that is in the event loop (like refresh) might cause the issue if it implicitely or explicitely changes the recordpointer.
>
>Its a nasty one to debug. We have managed to eliminate most of them, but once in a while, we see one at the error log at clients. At least with the TRY CATCH around the READ EVENTS, it does not crash our application and the user can just continue to use the application.
>
>
>Walter,

Yes, I agree, this one is very tricky to duplicate or troubleshoot. I was thinking about putting the READ EVENTS inside a TRY CATCH but I was concerned that it may crash the app. Good to know that you already tested this approach and found that it would not crash the app. I will try this approach, probably just on a customer or two that do get this "nasty" issue.
Thank you.