Ben,

would you explain a little bit the idea of "wrapper" business object?

The BusinessObject = 1 table is slightly problematic in the case when you would need to create a object that would include columns from several tables (a SQL join)  and perhaps some computed fields (some computation rather done in the database than in the application).

In a Oracle environment would DDT bring any help on this issue? 

Lastly, is this true: the data structure of the business object is just a place holder and the query populating the data structure can be whatever, e.g any SQL-statement?

Kari

So, ask away... we've got lots of the answers, and Google has the rest

Ben:

Thanks - I suspect the wrapper will be the way I go. As a new user, I have a long way to go, so crawl, walk, run, and many questions to be answered over time.

Thanks again,

Flavelle

You can either build a "wrapper" business object that contains the other 3 business objects, or you can map the business object to an updatable view.  We are making some changes to the Database Deployment Toolkit right now that will allow you to specify the primary key for a view, thereby allowing a business object to update it through the "instead of" stored procedures.

What is the best way to structure a Business Object, Customer, that uses data from multiple tables, say BusinessEntity and Address? I gather that a Business Object = 1 table. If this is correct, then I will probably need to get into transactions in order to ensure that adds, deletes, and updates to Customer are consistent in the database.

If I use a view, then should I build the stored procedures in the database for insert, delete, and update, or should I use transactions against the source table in the Business Object?

thanks,

Flavelle