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

Glad it will get you what you need.

Trent.



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



Thanks... that will do nicely.


________________
_____/ 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.

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

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 thought maybe I could create a view that was identical to the table then just exclude the column from the view. Then use the view in the mapper for the structure. But when I tried to save my changes it said it couldn't create an update statement because there were no PrimaryKeyFields. Is that an error because I cant bind a view to the BO or am I missing something?

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 didn't read the entire thread.  I was just assuming to exclude the strong-typed property.  Oops.

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.

Ok, I don't think its working. I added the carriage return and it saved the custom code but didn't exclude the field from the BO.



Here's the real reason I'm asking about excluding a field...I have a table that has a primary key composed of two fields. Neither of these fields is an autonumber... they rely on the combinatio of the data in both these fields to be unqiue to form the primary key. Then I have a field called UniqueID which is an autonumber field but it isnt a primary key. So when I edit these records and then try to save the changes it's throwing a fit because it can't update the autonumber field. I thought if I could just exclude the field from the BO that would solve the problem, but maybe thats not the approach you would suggest.