>>>Nadya,
>>>
>>>You don't need a PK for an updatable view. Just tag all of the compsite key fields as the key in the view designer. Of course, a PK puts less strain on the database engine and reduces the size of the WHERE clause.
>>>
>>>- Keith
>>
>>Keith,
>>
>>The problem is: one field in Integer and two other fields are character. Will it work? I want to discuss the possibiities with my manager.
>
>Since VFP uses the tagged key fields in a WHERE clause, I do not think the different data types will be a problem.
>
>> One quick related question: Append from doesn't update PK (if it has default value set), right? So, I had to re-write all code to use scan insert endscan instead, if I choose PK route...
>
>You can make the key fields in a view updateable too. If the base table is VFP, the data from the view will override the default value. This applies to composite key fields and PKs. If you are concerned with APPENDing data into a view based on a table with a PK, make sure the PK field is not updateable in the remote view for normal operations. OTOH, If you are copying an entire table and want to include the PK, mark it as both the key and updateable. The view engine doesn't use keys to determine if a record was appended. It puts a negative number in the recno() to differentiate appended records from updated ones.
>
>I usually create a remote view for copying an entire table and another remote view for normal query/update/insert operations.
>
>- Keith

Hi Keith,

Actually, this view will only allow update records (no add or delete). My concern was: I have another application, which automatically inserts bunch of records into this table using APPEND FROM command. If I add a PK to this table, should I re-write this piece of code to use scan instead?

Thanks again.