>>>>Just a minor note: there are certain situations when SEEK/SKIP cursor will be blazingly faster than p-view, even full Rushmore optimizable.
>>>
>>>Edward --
>>>
>>>Interesting note. I would like to understand it a little better. Is this because the view is based on SQL SELECT, while using SEEK and SKIP would work directly on the cursor? Or...?
>>>
>>>Thanks -- Bill
>>
>>Yes, SEEK/SKIP/INSERT INTO CURSOR will work much faster (much may mean 5-6 sec on slow machines) than SELECT_SQL running against big table (let say >300K recs) located on network, when SET DELETED ON.
>
>I can see where that would definitely make the grid snappier, but wouldn't it take some additional time to update the child table from the cursor?
>
>Thanks again -- Bill

Actually, not. When you update from view, it's really just one command (TABLEUPDATE()) for you, but behind the scene view is still a cursor, and there is some transaction code running there. Certainly, good programming approach for cursor solution would include having some additional cursor.field (logical) to mark actually changed records, so transaction will not cover extra records.