On May 17, 2009, at 4:18 PM, Miguel Lopes wrote:
> No. The design is good. Here an Opportunity is not a possible future
> account
> (customer). Trust me, the data is as normalized as it should be.
> An Opportunity is like a "project" the Account has. You can think of
> it like
> having the opportunity of selling/extending a new app to an existing
> customer because they are, for example, opening a new branch office.
I guess I don't understand your design. It still sounds to me like
you have: Account - 1:M - Contact. 'Opportunity' sounds like it is
related to Account, and only indirectly to Contact. Either way, it
sure doesn't sound like you have Contact - 1:M - Account/Opportunity,
so I'm not sure why your examples describe Contact as the parent object.
Having said that, you can programmatically 'switch' your Contact
bizobj by changing the SQL directly; i.e., by setting the UserSQL
property. When you do that, none of the 'addField', 'addFrom', etc.,
values will be used; in fact, they aren't needed at all. Just set the
UserSQL on the fly to the correct joins for whichever case is your
current need, and then requery away.
-- Ed Leafe
_______________________________________________
Post Messages to: Dabo-users@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message:
http://leafe.com/archives/byMID/fd32f55f-7752-4b5d-bd47-c0fa46c0b...@leafe.com
