>>I find it interesting that the SQL Inserts into the parent and child tables are not taking any time, but the tableupdate() from the view is. I have the view set to do SQL-Updates on Key and Modified fields.
>>
>
>You didn't say if you were using Local Tables or Remote... but... Jim hit on the problem... but, I don't think his advice is pratical, since you would end up having an index on EVERY field in the table that you would ever possibly update, which would be all of them.
>
>Lets say you have a table with 50 fields... and your user changes 30 of them and presses save... you do a tableupdate()... Well... since your Update is set to Key and Modified fields the update is being built with ALL modified fields in the where...
>
>update blah set blah=blah,blah=blah,blah=blah where ;
>PK = pkvalue and field1=oldvalue1 and field2=oldvalue2 and field3=oldvalue3
>etc till all 30 modified fields are in the where...
>
>Now, foxpro try's to resolve this query in your 500,000 records with rushmore, which pulls tons of records over.
>
>Change your update type to Key Field ONLY! And watch the update fly. This is the answer...!!!
>
>Once you realize how fast this is you will see how writting your own conflict resolution is so much faster. Basically loop through all the fields comparing OLDVAL() with CURVAL() and if they are all the same there is no conflict, do the update. I think there is a way to make sure that while you are doing this conflict resolution noone else does an update.
>
>Actually, all this info came from Ed Leafe who made a recent modification to CodeBook 6.0 to put the conflict resolution in the framework since the Key and Modified fields update is so skanky and slow!
>
>You would think, FoxPro would be smart enough to find the record with the Key, then check for conflicts... rather than just building such an ungly update statement.
>
>Perhaps someone close could mention this to Randay Brown or Calvin Hasia... I
am sure they could fix it!
>
>BOb


Thanks for the explanation.

Tom