> The WHERE clause of the lookup set is, of course, ignored, once the set is
> being polled by the parent for the unique row that matches the lookup
> key. For polling, the parent set replaces the entire WHERE clause
> (SQLWhereItems) with its own, i.e., in this case, WHERE lookup_field =
> polling_keyfield. That means that your WHERE clause is unstable.

That's exactly the point, that was new to me. I expected, that IBO adds
the WHERE clause and not replaces it. It's still a little bit strange to
me, but when IBO works that, I have to live with it.
There are a two possible (client) solutions:
1)
select distinct(PCID),
PCPAID,
PCMPID,
PCNR,
PCNAME1,
(select PANAME from PRODUCTAREAS where
PAID=PRODUCTS.PCPAID) as PANAME,
(select MPNAME from MAINPRODUCTGROUPS where
MPID=PRODUCTS.PCMPID) as MPNAME,
PCTARGETRELEASEDATE,
PCLISTPRICE,
PCRRP,
PCDAYONE,
PCMINORDERQUANTITY
from PRODUCTS join ORDERITEMSTABS_MP on PCMPID=OMMPID
where OMOAID=3
and PCACTIVE=1

or 2)
select PCID,
PCPAID,
PCMPID,
PCNR,
PCNAME1,
(select PANAME from PRODUCTAREAS where
PAID=PRODUCTS.PCPAID) as PANAME,
(select MPNAME from MAINPRODUCTGROUPS where
MPID=PRODUCTS.PCMPID) as MPNAME,
PCTARGETRELEASEDATE,
PCLISTPRICE,
PCRRP,
PCDAYONE,
PCMINORDERQUANTITY
from PRODUCTS
where PCMPID in (select OMMPID from ORDERITEMSTABS_MP where OMOAID=3)
and PCACTIVE=1

I prefer the first one, because it's faster.

Regards

Guido