>Here is an example.
>This is the first view (which is a view of the table), and it's updatable....
>
>SELECT Test1.test1_pk, Test1.field1, Test1.field2;
> FROM ;
> data1!test1
>
>..........................................then here is the second view, which is a view of the above view, and it's also updateable...
>
>SELECT Lv_test1_toplevel_rvwru.test1_pk,;
> Lv_test1_toplevel_rvwru.field1, Lv_test1_toplevel_rvwru.field2;
> FROM ;
> data1!lv_test1_toplevel_rvwru;
> WHERE Lv_test1_toplevel_rvwru.test1_pk = ( ?lnTest1_pk )
>
>DBSetProp(ThisView+".test1_pk","Field","DataType","I")
>DBSetProp(ThisView+".test1_pk","Field","UpdateName","data1!lv_test1_toplevel_rvwru.test1_pk")
>DBSetProp(ThisView+".test1_pk","Field","KeyField",.T.)
>DBSetProp(ThisView+".test1_pk","Field","Updatable",.F.)
>
>,,,,,with all that being said, generally I only do something like this if I have a really good reason too. Usually it's when I have several very complex remote views that I want to join together and I'll make a local view for that. This is often quite handy if you're trying to join data from two different systems (like an Oracle backend and a SQL server backend). Doing this with one local view of one local view seems a bit odd to me though since you're not joining two views together - I guess I just don't see why you wouldn't put it all in one view to begin with???

You're using the view's actual name, not dealing with Mere Mortals renaming it. My 'really good reason' was to give me a bit more Cancel Changes ability. The first view loaded the all records for a customer, the view_of_view only presented a subset (pending orders, previously shipped, payments) that could be altered individually. They were on pages of a pageframe, and I didn't want a save/discard changes every page activate when querying for the new subset.

Looks like I'll have to sacrifice the Cancel ability and change the first view to do the subsets directly.