Newbie ? - why DataPortal_Update not called on save?

Newbie ? - why DataPortal_Update not called on save?

Old forum URL: forums.lhotka.net/forums/t/2015.aspx


NeedCSLAHelp posted on Thursday, December 21, 2006

This is CSLA 1.5? (I think 1.51)

My experience with CSLA is mostly around working with some objects created by another developer that inherited and override a good deal of CSLA functionality (some good, some not so good, some I think stricly for the purpose of being confusing). 

At any rate, I'm creating a new class inherited directly from BusinessBase.  The object creates, gets populated etc. just fine.  For some reason when I call the .save method, the Protected Overrides Sub DataPortal_Update() method does not get called.  Sorry if this is such a simple question - just really at a loss here.

Q Johnson replied on Thursday, December 21, 2006

You should be able to step through this if you are using the Debug versions of the CSLA library in your app.  But Save calls the DataPortal's method (CSLA's code) that checks to make sure the object IsDirty before going through the hassle of using reflection to get a reference to your object so it can call the object's DataPortal_Update (your code) method.

Are you sure your object IsDirty?

NeedCSLAHelp replied on Thursday, December 21, 2006

Thanks Q and Shawn --- No, the object wasn't dirty, yes it's working fine now, yes, I'll apply a bandage to my forehead from injury that occurs when banging head on desk.

And yes, part of the confusion was migrating this class over from the inherited stuff done by someone else. 

I'm going to be moving over to V2 of CSLA soon, and hopefully will get away from all of the "Subclassed CSLA - The confused edition" stuff that I have to deal with now.  (Yes, sometimes it's like a bad horror flick)

shawndewet replied on Thursday, December 21, 2006

Nah I remember in CSLA 1.5 the very first line in our DataPortal_Update methods was "If Not IsDirty Then Exit Sub".  It is only in v2 that I found that this check for IsDirty is now done within the CSLA code.  I guess your only option here is to step through the CSLA code.  I suspect the "override a good deal of CSLA functionality" you mentioned is the cause of this issue.  Good luck.

Copyright (c) Marimer LLC