>>>Carlos,
>>>I think you wouldn't want to do this (I did). Instead of using the large child, select related child recs into a read&write cursor, use table buffering, edit/append, loop through modified and update original. It's exceptionally fast with large tables.
>>>Cetin
>>
>>Well, if there are not other solution i'll do it. What about a updatable view? I've asked this to edwars pickman too, but i've never used views.
>Sooner or later you'll use them and a good solution. But I wonder if it will be an answer to your speed problem (if a parameterized view then probably would). I still couldn't get why a child grid would be so slow. Are there many deleted recs and no tag on deleted ? (Already I know you use no set filter nor activerow). Might it be your calculations should be optimized ? ie: how do you calculate (each time and SQL or scan..endscan) ?
>Cetin

My calculations are only numeric ones from fields on the same record of the table. No need to move record pointer. sample: (mutua.base * mutua.indice / 100). I've supressed other ones like count, select etc.