No, the structure of DataTable inside the business objects is completely flexible... it can have extra columns, or even not all of the columns that are defined on a business object.  We have several users who are building their business objects off of views and using stored procedures to both select the data into the business objects and save the data back to the multiple tables.

Hi Guys,

I'm new to SF and most of our tables have columns that are maintained by triggers, e.g. date created, last updated etc and it was my intention to simply create views which excluded these columns. My concern is (with respect) this seems pretty 'obvious' way of doing things but it wasn't mentioned in response to the original question. Does this mean there are issues with using views as bo data sources and have matching stored procedures when filling bo's at run time.

Cheers, Peter

I've successfully just not included fields in the returned data. I.e. if you have 12 fields, but only need 7, just reference those 7 fields in the select statements that retrieve the data. Then just remember that when using that Fill method not to reference the fields not included.

Hi,

What if to not download unnecessary data to workstation to improve performance in certain process or screen?

At the moment, no.  However, there is really no additional overhead having those properties there.  If you do not reference them then it is as though they do not exist.  What is the reason you want to prevent the other properties from being created?

I was just wondering. Lets say I have a BO mapped to a table with 12 fields

is there a way to have the BO only map to 5

thanks Brad