03-09-2023
12:43 PM
- last edited on
05-25-2023
05:43 AM
by
JackLacava
After validating data in the XFSqlTableEditorSaveDataTaskInfo.EditedDataRows property collection, if a record fails validation, I set the XFSqlTableEditorSaveDataTaskResult.CancelDefaultSave property on saveDataTaskResult = True and return it. SQL Table Editor still saves the data. Same if I set it to False. Am I missing something?
Code:
For Each xfRow As XFEditedDataRow In saveDataTaskRows
isValid = validationHelper.IsValidDetails(xfRow)
If (Not isValid) Then
saveDataTaskResult.IsOK = False
saveDataTaskResult.Message = $"{saveDataTaskResult.Message}
{Environment.NewLine}
{validationHelper.validationMsg}"
saveDataTaskResult.ShowMessageBox = True
'SQL Table Editor still save the updates
'regardles whether this Is True Or False
saveDataTaskResult.CancelDefaultSave = True
Exit For
End If
Next
Return saveDataTaskResult
03-10-2023 04:29 AM - edited 03-10-2023 04:29 AM
I'm not terribly fond of SqlTableEditor, partially because of the woeful lack of documentation 😅 but I suspect there might be a little bug or something. As a (untested) workaround, have you tried clearing the list of edited rows?
Dim saveDataTaskInfo As XFSqlTableEditorSaveDataTaskInfo = args.SqlTableEditorSaveDataTaskInfo
saveDataTaskInfo.EditedDataRows.Clear()
03-10-2023 10:38 AM
@JackLacava, yes, I've tried calling clear() as you've shown with (I think) no effect. Could be the unit test where I tried it had slightly different conditions, it was a couple of days ago. I can try again.
03-10-2023 05:52 AM
Hi, what does the rest of your code look like? I assume you have something in there such as BRApi.Database.SaveDataTableRows() which already saves the data in the table. After this, you have to saveDataTaskResult.CancelDefaultSave to True to avoid the data being saved as per default (again) and not as per definition in your prior code.
If that is the case here, you may have to apply your validations within the prior loop and not execute BRApi.Database.SaveDataTableRows() using a Boolean.
03-10-2023 10:34 AM - edited 03-10-2023 10:50 AM
@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.
03-14-2023 05:00 AM
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.
03-14-2023 10:37 AM - edited 03-14-2023 10:48 AM
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.