Bug when saving object Using SP (csla 3.51)

pandelaras posted on Tuesday, September 23, 2008

It seems that when i use the following code to insert an Editable object, the save function fails to return the proper object. It returns an object with 0 as primary key. The primary key is m_iD_E3. The same code works fine with CSLA 3.0.3.

 Protected Overrides Sub DataPortal_Insert()
        If MyBase.IsNew Then
            Using cn As New SqlConnection(database.elOGISTIRIOConnection)
                cn.Open()
                    Using cm As SqlCommand = cn.CreateCommand
                    cm.CommandText = "AddENTYPO_E3"
                    cm.CommandType = CommandType.StoredProcedure
                    cm.Parameters.AddWithValue("@ID_E3", m_iD_E3).Direction = ParameterDirection.Output
                    DoInsertUpdate(cm)
                    cm.ExecuteNonQuery()
                    m_iD_E3 = DirectCast(cm.Parameters("@ID_E3").Value, Decimal)
                End Using
            End Using
        End If
    End Sub

The function is working properly and the SP saves the item to the database and the correct key is returned. But the returning object has the default (0) value. This is a problem i run into when i changed my CSLA version from 3.0.3 to 3.5.1. I tried to trace the problem and it seems to be a reflection problem somewhere but i cant be certain.

JoeFallon1 replied on Tuesday, September 23, 2008

I can guarantee you that the problem is your code. I will also bet you a beer that your code looks like this:

mBO.Save()

But in order for it to work correctly it must be like this:

mBO = mBO.Save()

You are simply not updating your references when saving.

OK - so why did it work in 3.0? Well, if you read the change log Rocky stated that he planned to change the DataPortal behavior in 3.0 so that it acted the same way locally as it does remotely. But for 3.0 he set the flag so that it defaulted to the older style (incorrect) behavior. He also clearly stated that he was going to switch that default in the next version (3.5) so that all your bad code would break. He thus gave you a full version of warning to fix your code.

There are two solutions.

1. Fix your code. (Recommended)

2. Set the flag to the old incorrect behavior. (Bad idea - but will let your app still work in the short run.) See the blog or change log for the name of the flag. I do not recall it off hand.

Joe

 

 

pandelaras replied on Wednesday, September 24, 2008

Thank you. Indeed the problem was my code in the aspect you mentioned.