I have a table that contains 2 columns, updated_on and updated_by, that are updated by an update trigger in the database (SQLServer 2005).  The BO's fill method uses a simple "SELECT * FROM TABLE" statement.  Whenever I update a particular row more than once using the same instance of the BO, I get a data collision on the updated_on column.  Since the user doesn't directly update the updated_on/by columns I changed the SELECT statement in the BO not to return them.  The data collision problem has now gone away.

Should I keep columns updated by triggers out of updateable BOs?

Well, you could accomplish this in on of a couple ways:



1) Let the business object handle the updatedby and updatedon columns. You can add the FieldPropertyChanged event to the business object(s) through the BOMapper, and set the updated properties in that event. When you change one of the properties, the business object updates its field.



2) Add a column for row versioning. Basically, by default, the business object will check all of the columns against the columns in the database to see if the row has been updated (causing a concurrency exception). When the trigger updates the row, the business object thinks that another user updated it because it doesn't know the difference. You can change the UpdateConcurrencyType property on the business object(s) to RowVersion and use an INT column to hold the row version. When the BO saves, it will update the row version, and when the trigger updates the table, it won't update the row version column, so the business object won't know someone else is modifying the record.



Row versioning is also more efficient than the default concurrency verification type because you're only testing one value rather than 3 tests for each column (but row versioning requires you to change your data structure, so we couldn't make it the default).