Ok, found it.   That was smart so you could set a created by that only updates on Insert but does not ever get updated.  Slick.    You should put this in the Business Object Mapper as well in the future as it is a little tedious to type ( Sorry I'm a little lazy by nature ).  

Thanks for providing this and I can pull out the junk code i had to work around computed fields.

Richard

Nope, every business object has a new property called FieldsToExcludeFromUpdate and FieldsToExcludeFromInsert... they should normally be the same, but you can set them to an array of field names that should be excluded from UPDATEs and INSERTs, respectively.

I upgraded to 1.6 and was looking for the 'updateable setting' metioned.   Is it an enhancement of the read only property not to update back to the db now?  

Richard

Excellent!

All fields contained within the AllFieldsList() property will be persisted back to the database.  This property is automatically created with the BO mapper and resides within the BOs respective designer.

You can create a custom property, calculated field, that is not contained within this list and it will not be persisted.  Please refer to the "Adding Custom Field Properties" topic in the help for further information.

NOTE: In the next release 1.5.2 you will be able to exclude a specific field from updating.

Well, I just noticed that you can mark a field as readonly in the BO mapper. It creates a readonly strongly typed property for the field. I'm wondering if this also means that the BO doesn't try to update the field during updates and if it skips the field if calling a sproc to update/create a record?



If so, then calculated columns are already handled

That's part of the updateable setting that I mentioned above.  I think that maybe the boys from Strataframe can enhance the framework here for this specific reason.   Otherwise you'll have to use an UpdateStoredProcedure and code out the Database Computed Field.

Rich

Richard, how are you handling the calculated columns now, with the current BO technology?



(I'm going to have to deal with this soon )

I've really been thinking about this concurrency issue within Strataframe and wonder if an option could be created to allow the where clause during the update to be dynamically assigned. 

Something like:

Where Clause = Primary Key -  This allows the update no matter what

Where Clause = Modified Columns - This allows the update to only focus on columns that have the concurrency collision

*** SLICK FEATURE ***  Where Clause= Key and Updateable Columns where we can define an array of columns( or better yet have Strataframe Business Object Mapper allow us to define this !!!!! ) that are updateable to the Database.

I personally do not like using Stored Procedures for updates because to enable Option # 2 you have to pass the Original Value and the Updated Value.  This kills option 1 where I would like to update the record no matter what or I have two update procedures which is just as annoying to maintain. 

The sample previously of updating the Database Balance Column is what triggered my thinking because in my system the Balance is a summary column of detail records updated by triggers and I want the Business Object to display but never modify.

I think that this would be fairly easy to implement, what do you guys think?

Richard

The SqlDataSourceItem class is creates the paramters like this:

So, I'm not sure why the parameter direction is still Input.  It should be Output.  As for the GUID being initialized to 00000000-0000-0000-0000-000000000000, I believe I told you incorrectly to set the Me.CustomerID property directly.  You'll have to go around the strong-typed property and set the field within the CurrentRow: Me.CurrentRow("CustomerID") = DBNull.Value.  The property will not accept null values...