XFSqlTableEditorSaveDataTaskResult.CancelDefaultSave = True - has no effect?

Valued Contributor

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?






For Each xfRow As XFEditedDataRow In saveDataTaskRows
	isValid = validationHelper.IsValidDetails(xfRow)
	If (Not isValid) Then
	    saveDataTaskResult.IsOK = False
	    saveDataTaskResult.Message = $"{saveDataTaskResult.Message}
	    saveDataTaskResult.ShowMessageBox = True

	    'SQL Table Editor still save the updates 
	    'regardles whether this Is True Or False
	    saveDataTaskResult.CancelDefaultSave = True 
	    Exit For
	End If
Return saveDataTaskResult









Honored Contributor

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


@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.

Valued Contributor

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.

@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.