Thanks to you both - I had run coverage logger for a couple other issues recently, but neglected to try here. I thought valids ran before the rowchange events, but will be curious to see in CVP. Will do over the weekend and report back.


>>I have a grid in a formset that has a peculiar problem. The grid is databound to a writable query, which updates the underlying table upon row/column change. I have figured out that if you tab out of the field for a column change, the code below works perfectly. However, changing rows will 95% of the time not update the table with the replace statement. The weird part is, if I trace through the method, it always works. I have to set a code break after the replace statement to see that the replace doesn't work.
>>
>>Example: If I change a field from "25" to "35"
>>if I stop the code immediately below the replace statement, I get:
>>jcwolabor.milebill = "25" (not updated)
>>labtempdet.milebill = "35"
>>
>>if I do the same and move right or left, they both show "35"
>>
>>If I stop the program immediately before the replace statement and step through the code, it works no matter which way I move - very frustrating.
>>
>>Here is the grid.beforerowcolchange code:
>>

>>LPARAMETERS nColIndex
>>
>>= thisformset.calcot()
>>replace hours WITH thisformset.calcreg, othours WITH thisformset.calc_ot, dthours WITH thisformset.calc_dt IN labtempdet
>>
>>IF SEEK(labtempdet.labkey,"jcwolabor","primary")
>>	SELECT jcwolabor
>>	replace jcwolabor.dos WITH labtempdet.dos, jcwolabor.desc WITH labtempdet.desc, jcwolabor.techid WITH labtempdet.techid, ;
>>		jcwolabor.truckid WITH labtempdet.truckid, jcwolabor.timestart WITH labtempdet.timestart, jcwolabor.timeend WITH labtempdet.timeend, ;
>>		jcwolabor.mileage WITH labtempdet.mileage, jcwolabor.milebill WITH labtempdet.milebill, jcwolabor.milerate WITH labtempdet.milerate, ;
>>		jcwolabor.hours WITH labtempdet.hours, jcwolabor.laborrate WITH labtempdet.laborrate, jcwolabor.othours WITH labtempdet.othours, ;
>>		jcwolabor.dthours WITH labtempdet.dthours, jcwolabor.billhours WITH labtempdet.billhours, jcwolabor.billot WITH labtempdet.billot, ;
>>		jcwolabor.billdt WITH labtempdet.billdt, jcwolabor.tripcharge WITH labtempdet.tripcharge, ;
>>		jcwolabor.updated WITH DATETIME(), jcwolabor.updatedby WITH ALLTRIM(STR(o_app.loginid)), ;
>>		jcwolabor.comment WITH labtempdet.comment IN jcwolabor
>>
>>ELSE
>>	WAIT WINDOW NOWAIT "Unable to save to jcwolabor..."
>>ENDIF
>>

>>
>>note: the seek always seems to work - the record pointers appear to be in the correct place when I've stopped before and after the replace statement.
>>I left the calcot method in the example, but all it really does is recalculate fields in the existing field, so there shouldn't be any pointer change on labtempdet.
>>I originally was doing a replace with a for clause, but it had the same result. I have also tried a SQL update statement, with the same result.
>>I have taken any buffering off the jcwolabor table - same result. This is happening on two different form/grids in the formset, so I assume this is expected behavior and I"m missing something obvious...
>>
>>What am I missing? Any thoughts would be greatly appreciated!
>
>Use SET COVERAGE TO and Martina Jindrova's CVP utility to see the source code being executed, to convey which lines are run in which order. It will reveal timing as Christian Isberner indicated, with source code to see how things fired.