Hello Wendell,

Yes, each updateable view needs to include the table's PK... and yes, it should only attempt to update one table at a time :)

Anything that works with your data tables should use a data environment. VFP local views were our standard, but we were bitten pretty hard when we needed to migrate to SQL and found that too many "programmers" were USEing tables directly. Views are definitely the best way to go. This also applies for lookups.

You can add lookups to the same data environment as your main/updateable view... we did this when the object using that data environment always needed those lookups (e.g. OrderBizObj and all the marketing info used to create an order). Otherwise, we created lookup environments to group similar functionality (e.g. CustomerSearchLookups)

Not sure I'm following your questions on parent-child relationships?
---J

>I have just started using MM 8.1 framework. I am trying to make sure I separate my application from my data(I am used to writing to buffered tables) so I can switch in the future from local to remote views. I am trying to make sure the views are set up correctly. Am I correct that, in order to do this all views that I want to update must have a unique key and even If I don't want to update a table but only use it as a lookup table, I would also create a view for this? Is it recommended to create at least one view on each table I use in the project?
>
>Having asked about views whats the best way, using views, to set up a foreign key in a normalized set of tables where the details table needs to be linked to a parent table?
>Does the child table need to have a unique key in the view as well?
>
>Any help with this will be greatly appreciated!