>>>>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.
Carlos,
So we are nearly having no more choice than a view. Your buffering was pessimistic ? What about setting it to optimistic and only parent to pessimistic ? Pls this time some performance gain.
Cetin