I have a BO where I select some additional fields from another table in a custom fill method to populate some custom fields. I'm using stored procedures that were automatically created by DDT to handle the inserts and updates. I'm also using Optimistic Timestamp for concurrency. When I run a single instance of the application everything works fine. However when I run two instances and enter updates that are designed to cause a concurrency violation, the second instance to call save gets an unhanded exception during the save. The inner exception lists the added fields as invalid column names. I haven't traced the code (since I don't have the v1.61 source) but I'm wondering if the code that handles concurrency issues is using the column names from the data table rather than the AllFieldsList. I also tried adding the additional column names to the FieldsToExcludeFromInsert & Update but still get the same error.

-Larry

That's a very good thought, Larry, I'll have to check and see if the concurrency comparision is checking the DataTable and not the executed command (which will only contain fields from the AllFieldsList).  I'll check.

This issue is likely related although it happens both inside and outside of a transaction. I have  parentBO and childBO that both contain some columns added with a Select statment. I delete the parentBO by marking it as deleted. The related child records are automatically marked as deleted. When I try to save the child I get a message listling all of the added columns as invalid columns. Right now I'm working around the issue by breaking the parent/child relationship (ParentBusinessObject = Nothing) just before the save and restoring it afterwards.

-Larry

Larry,

Just add the columns that do not belong to the table to the ExcludeOnInsert or ExcludeOnUpdate properties.  By adding the columns that do not necessarily relate to the table you can have your cake and eat it too...so to speak

I tried that. Like the original issue I was having with concurrency checking, adding the fields to the "ExcludeFrom" lists doesn't work.

-Larry

I reverted back to v1.6 from 1.61 beta so I could step through the source code and I believe I've found the source of the problem. To recap I have both a parent and child BO with fields added from other tables when the BOs are populated. The database is configured to cascade the deletions from the parent to the child. 

When parent is marked as deleted and the BOs are saved, the parent is deleted and the database cascades the deletion to the child records. Next the child BO is saved. Since the child records have already been deleted in the database, lnReturn in SqlDataSourceItem.UpdateRow is set to zero. The code following the command execution considers lnReturn < 1 to be a concurrency exception. Eventually DataLayer.GetRowFromServer gets called. The query that gets built uses the data table column names, not the AllFieldsList. It also ignores the "FieldsToExclude..." defined on the BO. The result is that the added fields are included in the query which causes an invalid column message to be displayed when the query is executed. This is also causing an issue when there is a real concurrency violation.

Breaking the parent/child relationship and then first saving the child followed by the parent works since in both cases lnReturn > 0 and the concurrency handling code is never called.

On a related subject I know that the SF position is that the deleting of child records should be handled by the data base. However it seems that if the framework were enhanced to save the child records before the parent on deletes, it would handle the majority of situations.

Finally I posted another question regarding timeouts when saving BOs with a parent/child relationship on a transaction that was never answered. http://forum.strataframe.net/Topic9625-10-1.aspx?Highlight=timeout

-Larry

We are going to take a look at the other post....sorry we missed it

Yep, just fixed it, Larry... I also changed the comparison of the field collisions to ensure that only columns that exist in both the retrieved server row and the local row are compared for a possible field collision.  Will be included in final 1.6.1 release.

Thanks Ben!  I'm using added columns on just about every BO in a new project so getting that fixed is a big help.

-Larry