Is there a way to exclude fields from being used in the BO?

No, what you need is the ability to exclude a column from the update.  Paul Chase is running into the same problem with his RowGuidCol he's using for replication... you can't update is once it's been INSERTED.  I'm running through the possible options right now.  Easiest thing would be to have a property where you declare the columns that should be excluded from updates.

I didn't read the entire thread.  I was just assuming to exclude the strong-typed property.  Oops.

That's what I assumed at first as well, then Mike explained what he was tring to do, and I noticed Paul was having the same problem with his guid values for replication.

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.