>I cannot open view1 with data since I don't know which data the user wishes to use in the report. When I know which data it is, it can be multiple values. Since I know of no way to create a multi-valued view parameter (which is usually the integer primary key value ) I populated view1 from the multi-select list prior to requerying view2, which didn't work.

Hi Gil,

I have a feeling you can accomplish what you want using an updateable cursor instead of view1 to hold ONLY the primary keys of the records you want to fetch through view2 and then for view2 use:

select yadayadayada FROM mytables_and_joins WHERE primaryKey IN (select * from my_cursor)

>So it brings me back to this:
>For a view (view2) based on a view to work, the based-on view (view1) must be directly populated from the underlying table via either a requery or open with data and NOT manually poplulated. Is this correct?

Yes and no. I think your view can be based on a view that's based on a view that's... you get the idea. I just tested it with the following:

create sql view view1 as SELECT * from CASES where iid > 24000
create sql view view2 as select * from view1 where iid > 24200

I closed all tables and then opened view2. View1 was implicitly requeried and the resulting cursor had only records with iid > 24200.

Here are the scenarios with updating data:
If I add a record to the TABLE (cases) I must requery view1 first and then view2 to have view2 in sync.

If view1 is updateable and I add a record to view1, I must requery view2 in order to get it in sync.

As Mark said, issuing a requery on either view will NOT update the contents of view2.

When view2 is FIRST executed, both views are requeried sequentially. After that, the data is actually held in temporary tables and updates to one of them don't result on the automatic requery of the other(s).

Good luck!

Alex