Hi, Gustavo-

>I have a situation in which the following piece of code behaves in different ways depending if I am debugging it(stepping through the lines of code) or not.

Yep. That's common. It's particularly true when debugging something that relies on refreshing, as in your situation. The reason is because events fire when objects get and lose focus, yes? So, when the debugger breaks, or you step back and forth, the objects in the app are getting and losing focus. Which might be a hint for your bug. The reason the debugger works this way is because the debugger is running the same process as the application you're debugging. It can make some debugging tasks difficult.

>

>* ZAP the table that holds the current configuration
>* New configurable items will be added.
>go_SQL.cmpA_tmpf14.m_Zap()
>WITH THISFORM
>  x_Loadbom(lcBomno, lcRevlev, lcLoctid, lcLintype, lnLevel, lnQtyUsd, .T.)
>  x_LoadCfgItems()
>  * GOTO TOP IN a_tmpf13
>  go_SQL.cmpA_tmpf13.m_MoveRecord(Cn_TopRec)
>  * GOTO TOP IN a_tmpf14
>  go_SQL.cmpA_tmpf14.m_MoveRecord(Cn_TopRec)
>  .grdCfg.refresh()
>ENDWITH	
>

>
>The form has a grid that doesn't get refreshed when running normally, but it is when I am debugging it. This grid should show changes made to its recordsource (a_tmpf14). What could be causing this behavior? Any clue? Any workaround?

I don't see in the thread where you said you're doing this. What method? Is it in a grid method or, say, a button method? Do you set the rowSource = "" before you do your processing? If you don't really need to ZAP, then, I'd suggest not, because as with pack, it rebuilds the data. OTOH, so would a requery of the data source for a temporary cursor.

HTH.