...snip...

>Yes it is. I have the same type of situation where I have a 3 tab page frame for setting security options [application level, table level and field level]. If there is an associated table with an application level of security, the 2nd page is enabled. If there are field level security options for a table option, the 3rd page is enabled. All of these sources for the respective grids have parameterized views as their source.
>
>There is no way around issuing a Tableupdate() before a Requery() of these views without generating an uncommitted changes error if changes or additions were made.

I guess I'll give up on using views. I think maybe I will just set filters for each of these tables. Then with table buffering I would still get my desired result being able to switch between skus and then go to page 3 and see the related serial #'s all without having to issue a tableupdate() I think? Are there any other downsides to using filters other than the scrollbar on the grids being proportionate to the entire table rather than the filtered subset?

Thanks again for everything,
Paul