>hey Dragan..
>
>Jeez this thing is driving me crazy..I haven't figured it out but have learned some more..
>
>I def. think you were on the right track..although I still can't recreate I think it actually happened to me today. I turned off all timers and was stepping through the code where it selects the recordsource for the grid and issues a ZAP. everytime i had gone through this code, it executes the ZAP and just moves to the next line. but this one time, as soon as it executed the ZAP, I got the Error 5..it wasn't giving me the option to Suspend(I don't know if that was cause I had the debugger open or what). the Error 5 was on the screen and the debugger was on the very first line of the BeforeRowColChange() event of the grid, code that never gets executed here(or at least that shouldn't get executed here). the alias() was correct, the recno() was 1 and EOF() was .T., all of which I thought looked correct..
>
>anyways, I'm looking into what could cause a ZAP to move the record pointer cause it appears that's what happened..

Zap does move a record pointer - to the first phantom record beyond EOF. I.e. you'd get reccount()=0 and recno()=1, which means you're at EOF().

Now the curious thing here is why did the grid try to do anything at this point. If you're already destroying your form (if I remember correctly)... then you could just set the grid's recordsource to empty before zapping, so the grid wouldn't try to do anything.

It's not that BRCC errored out, it's why did it fire at all. Now it could be your grid refreshing while you're in the debugger, but that wouldn't explain why does it happen at runtime. Is your form locked (as in .LockScreen=.t.) while this happens? I'm not sure whether that stops the grid from refreshing, but it might.

Look at message #1101912, it may explain the influence of debugger, if there was any.