Ann,

> You're right. There does seem to be a problem, but I don't quite

have

> it nailed. For the casual reader, I've put my definitions and

results

> and your definitions below my signature.
>
> It appears that the relevant source definitions are table t_a,

table

> t_c, and view v_c. You see the problems in a view composed of

table
t_a

> and view v_c. There's no reference to t_b, or v_b except that t_c

has a

> foreign key reference to t_b.
>
> My first thought was that the problem was with the two levels of c

which

> both use the same field names and alias, and in fact, my test case

with

> different field names and aliases does not show the error. So I

went

> back to your script and just took out the reference to table t_b.
>
> That fixed the problem. Without the foreign key definition, I get

the

> expected results, even with tables and views that share names.

Could

> you verify that? When I add the foreign key constraint, I get the
> unexpected results.

I created a fresh database and pasted your definitions (part 1).
The results I get differ from yours. For your first two selects
(before involving the foreign key) I get COUNT=1.

I tested this in WI 1.0.3 and WI 1.5.0.4306.

I get the same results as you, running WI 1.5.2.4731.
I will restore my production database to WI 1.5.2 and see if the
problem persists.

The second part of your test case seems to be missing something.
Where do table b and view v_avb come from?

> ////
> ////
> disconnect and reconnect here
> ///
> ///
>
> create table c (c1 integer not null primary key);
> alter table b add constraint fk_bc foreign key (b2) references c

(c1);

> commit;
>
> select * from v_avb;
>
> VA1 VVB1
> ======= ============
>
> 2 1
>
> select * from v_avb where vvb1 is null;
>
> VA1 VVB1
> ======= ============
>
> 2 <null>
>
>
>