Hi,

I am using DevExpress ASPxGridView to bind to SFUsersBO. When I delete record from ASPxGridView, it only "logical" delete record from BO. I need to call BO.Save() in order to commit changes to database.

I hit error "currentRowIndex is out of range" when I call SFUsersBO.Save(). I found that is logic in SFUsersBO.BeforeSave() to log the user changes via CurrentRow property. This cause the error.



How should I resolve it?



Note: error would occurred if BO only has one record. If that is more than 1 records, the change log would recorded wrongly.



Thank you

Well, this could be coming from several things.  I am not sure what version you are running on here, but we fixed a CurrentRowIndex issue in the 1.6.6 release that could have something to do with this.  So if you are running on a version older than 1.6.6, then the first thing to do would be to upgrade to 1.6.6.

Secondly, when you run into CurrentRowIndex issues, this can come from many places within your code outside of the standard framework logic.  For example, if your BO is empty, then a column is referenced....that would produce the error, as it should since there is no row available. 

I hate to be a broken record here today, but I would really need much more detail in order to help you isolate your problem.  But maybe some of these suggestions will point you in the right direction.

Hi,

it is simple.

In my situation, my SFUsersBO only has 1 record. I call SFUserBO.DeleteCurrentRow(true) for logical delete. After that, I call SFUsersBO.Save().

When I call Save(), SFUsersBO.BeforeSave() fired, and this event contains code to log changes. (originally from RBS)

Since record is deleted (logically), the code Me.CurrentRow in SFUsersBO.BeforeSave() cause error.



So, how should I resolve it without modify SFUsersBO code?



Thank you

Hi Chan.

I guess that the SFSUsersBO is meant to integrate into the RBS, and since a user can't be deleted throuh the RBS IDE, the BeforeSave is not expecting this situation. I douhbt it if it is a good idea, but maybe you could add a new BO to your solution and map it directly to the SFSUsers table, from SQL Server. Then you would be totally in control, I guess. And not sure this would be a good idea.