Henning, the rest of the code is validation, pass/fail.
I've tried using BRApi calls to save the data and without (current state). On an update to an existing record, I just want to let the UI object save as default on validation pass (isValid=True). I think this may answers why I'm getting erroneous duplicate records lacking some of the column updates preformed before the save, like adding a current date to a LastUpdatedDate column. The erroneous records LastUpdatedDate column would have the beginning of time for a date instead of Date.Now().
One problem I'm having that complicates the debugging here is the error shown below. It appears to be thrown directly to the user, bypassing all exception handling I have in place. Its Intermittent and seems to happen in different places - I've tried to isolate it's source Throwing XFUserMsgException in various places in the code. Then the row appears to not be saved, yet a refresh show it was regardless of state of CancelDefaultSave on the returned status object. I'm not on the latest version so I'm hoping things improve with an upgrade scheduled for next week.
Hi Robb, not sure what is wrong here, could possibly also related to the more general setup of the solution. I have not seen this error yet and so far the rules worked also in older versions when I used it. Could be that you are on a version that I have not tried it on and hopefully the upgrade will make a difference.
Thanks for this Henning. I hope this is version related. During the coded process of looping over the SqlTableEditorSaveDataTaskInfo.EditedDataRows eot evaluate for valid data, the data to be saved gets saved to the table before returning the XFSqlTableEditorSaveDataTaskResult object back to the calling dashboard control.
I can observe this by watching the table itself. Since the returned TaskResult object has a property of "CancelDefaultSave", I'm making the assumption that any saving that isn't coded explicitly to happen should not happen until the returned status object's CancelDefaultSave property is evaluated - which would happend after all my BR code is run. Yet the changes are being saved by something other than my code before the return.
To get around this, I loop over the EditedDataRows , validate as part of the loop, then query the table to delete the records unexpectedly added before several fields can be updated, then, if valid, add the updated and correct records with another SQL query.
My requirement is to allow a user to change parts of a record in a custom table, then, on Save, call a BR to validate those changes before allowing them to be saved. The BR process of validation is causing the record to be saved - even if the saved values are invalid for that record.
