You can bind a view to the business object, but only for displaying data from the business object, not saving back to the database.  The primary key is defined on the table, not the view, so when the BOMapper creates the partial class for the business object built from a view, it doesn't include the primary key.  You'll probably have to wait until I get the exclusions done for the updates.

I know this post is dated, but I have a need for this. Specifically, I want to control which of the columns in a business object will participate in an update or insert.



Here's an abridged version of what I am trying to accomplish: The user will be allowed to import transactions into an SF application. These transactions may represent:



1.) "Brand new" transactions (to be INSERTed into a SQL Server transaction table).



or



2.) "New" values in selected columns that should be merged into pre-existing rows in the same SQL Server table.



Note that in one set of imported transactions there can be a mix of both type 1.) and type 2.) transactions.



When the user initiates the import of transactions there's sufficient information captured to know--if it's case 2.) above--which columns are the ones to be updated (and therefore which other columns should be excluded).



Among the possible designs that come to mind for this is the use of an UPSERT stored procedure, although I think using UPSERTs may have complexity involved due to the inserts needing the full column set while the updates need a reduced set (need to think about this one more... perhaps that complexity really won't play out).



Another design solution would involve flipping a flag similar to what was discussed in this post to dynamically identify which columns are to participate in the SF-generated update or insert statements.



A final design solution I'll throw out would be to insert all the imported transactions (all columns) into a temporary table in SQL Server, then call a stored procedure (with appropriate parameters) and let it handle the INSERT or UPDATE into the actual SQL transaction table.





So, I think I want to ask:



1.) How can we include/exclude columns to participate in BO SAVE()s at run-time?



2.) What thoughts do you have on a good design to handle this?



TIA



_______| Additional Info on the Import Data Flow |___________________________

...just in case this helps...



The source of the transactions are VFP tables. I am currently loading those transactions into a BO mapped to the VFP DBF. I then have code that does some data migration/massaging (e.g., handling column name of data transformation issues) and populates an instance of a BO mapped to the SQL Server transactions table.

______________________________________________________________________




________________
_____/ Regards,
____/ al

Before I go into a longer explanation, I want to make sure that you are aware of the FieldsToExcludeFromInsert and FieldsToExcludeFromUpdate properties on a BO.  You can set these at design-time or programatically at run-time to omit certain columns from being inserted or updated.  This is generally how we go about this particular problem.  Please let me know if this will not meet your needs or if I am missing something.  Thanks.

Trent.



Of course I know about those properties..... I just sorta forgot, that's all!



Thanks... that will do nicely.


________________
_____/ Regards,
____/ al

LOL...no problem...I just sort of forget a lot

Glad it will get you what you need.