Thanks for the reply.

Let me see how this plays with what I'm trying to do.

I've got an order form with the orders bizobj on it. For whatever reason, I want to assign or change the customer associated with the order at any time (in my app. they aren't orders or customers, but the analogy seems to work here). I have a button on the orders form that calls up a modal form that has a grid that lists the customers. I pass in a reference to the calling form and use the default data session. I pick a customer and the modal form sends the id back to the orders form. The order form displays the pertinent customer data. from the customer view. The orders bizobj has a view of the customers as an "associated data access object" - i.e. a lookup view in the DE.

Is this a "bad" way of doing this? I should really set up an instance of the customer bizobj on the modal form with the lookup view in a lookup DE, leaving the maintenance DE alone? If I do, then I still need the customer view in the orders bizobj so I can display the customer data.

I guess from an OOP point of view, the customer lookup form should be stand-alone and not be dependent on the order form providing it with the lookup view.

Thanks for helping me to sort this out. Getting my mind wrapped around some of the OOP concepts is an effort at times <g>

June

>>What is the philosophy on setting up bizobjs? If a project has customer, orders, orderitems and products as tables, has a maintenance view of each, and 2 other non-updateable views of each (for lookup/reporting purposes, say), how many bizobjs and data environments should there be, typically?
>
>>What is the philosophy on setting up data environments - one per bizobj, one per form per bizobj or what?
>
>For me, 4 bizobjects, 4 dataenvironments. Each DE usually has multiple views, but only one (the default) is updateable.
>
>I recently found something that looked to let me change which view was the updateable one, but that's a little too black magic for me at this point.
>
>Chris.