Hi!

You should not make ANY logical sense for primary key. Otherwise you could quickly find self in situation when primary key is not unique. Primary key - is primary key, it should identify record in table and nothing else. Of course, if your table is so large that you're trying to remove everything extra...

Anyway, did you tried to play with view's keys more as I suggested?

>That's ok and I do setup my Home table that way but the MoveHistory file you can think of as like the line item table of an invioce. It is a foreign key type table and the primary index is a composite index. I can't give it a Primary Key as that makes no logical sense. See my problem?
>
>Terry
>
>>In view designer you can mark 2-3 fields as 'key' fields. In addition, you should define key field for both movehst and home tables. Finally, you may try to use "'Key and Modified fields' in SQL WHERE clause" option.
>>
>>If this will not help, use single auto-increment key field as recommended for most RDBMS...
>>
>>
>>>I became inspired by Jim Booth's book and decided to use a view for one of my edit screens. The view is a simple combination of two tables. I allow the edit screen to make changes and execute the following code on process.
>>>
>>>
>>> **************************************************************************************
>>> *** Save changes
>>> **************************************************************************************
>>> TABLEUPDATE(.T.,.T.,"MoveHistoryMaintenance")
>>> REQUERY("MoveHistoryMaintenance")
>>> ThisForm.Pageframecustom1.ActivePage = 1
>>>
>>>
>>>Here is the sql code for the view as specified in eview:
>>>
>>>SELECT Movehst.*, Home.h_full_nm FROM main!movehst LEFT OUTER JOIN main!home ON Movehst.home = Home.id WHERE Movehst.id = ?gnChildID AND NOT DELETED() = .T. ORDER BY Movehst.id, Movehst.in_date, Movehst.home
>>>
>>> All fields except h_full_nm are marked updateable (I don't want the home name changed as that is maintianed elsewhere).
>>>
>>>
>>> When two or more move records for the same client were involved the Requery generated an all kinds of warnings about violation of the movehistory file's primary key. This is a composite index composed of the client id + the move in date + the home id. The view update criteria just marked the client id as the key. So I reasoned that if I marked the rest of the fields I would be ok. No such luck this caused eview to complain about multiple keys. I tried to make a composite field out of the client id + the move in date + the home ID, call it 'key' , and set that as the key field. Again, complaints about not being able to map back to my source tables for a composit key. I am stuck. Obviously, I am missing some very important conceptual information about views and updates. :(
>>>
>>>
>>>I don't want to give up on the view concept as I am trying to move my programming technique to the Ntier level.
>>>
>>>
>>>Any help GREATLY appreciated.
>>>
>>>Thanks in advance
>>>
>>>Terry