>>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