I noticed that rollback doesn’t work like before, and perhaps that is caused, because of the fix that was made that table triggers were executed on rollback.
My situation is as follows:
In a table trigger there are checks on record-level, so that user will receive an error in case he has entered invalid value as defined in the business rules (like servoy consultants has shown us on Servoy World).
In case an errormessage was given, the tabletrigger returned false.
In my solution I did a rollback (I didn’t do rollbackEditedRecords() ) in that case and the record that was edited on the screen kept the values that were entered by the user. The only problem was that the errormessage was shown twice, because the trigger was executed on rollback as well.
Since the new version, I noticed a difference. User creates a new record, enters some values and presses OK, to write the record. The table trigger is executed and same errormessage is given. Again a rollback is done. But … the new record created, is not anymore on my form. The rollback also rollbacked the newRecord that I did on the controller/foundset. So what happens now, is that user get error and after error, record is lost, so user must do newRecord again, and fill again all fields, and perhaps pressing OK again and maybe other errormessage occurs (due to business rules) and record lost again.
That is unacceptable for an end-user.
So I want to know if there is another solution, so that errormessage can be shown (this check must be on record-level, not on form-level), and the changes on the form (only on the form!!!), will be kept. Just like it worked in the previous version. Or perhaps review the rollback command.
Martin,
When you do a rollback, you will revert to the last saved state, so edited but unsaved records have to be removed from memory.
Why do you have to do a rollback?
Without the rollback, the values entered by the user are still on the form.
Rob
Hi Rob,
The table event triggers are used for both record validation and additional updates. And within the table trigger other (global) methods can be called (or even other table events when updating another record).
So I don’t know if a table trigger only has done record validation or also additional updates.
Therefore I must do a rollback, but I want to keep the original values that are on my form.
I have now programmed in my coding on certain places rollbackTransaction() and on certain places rollbackEditedRecords(), because sometimes the transaction must be rollback without making rollback of the changed record in memory (only on the visible form)
Now all user changes on the form are rollbacked even when just one record validation fails. And we don’t want that after each validation error, that user must re-enter changes again.
I hope you understand the situation.
Kind regards
Martin
Martin,
Is it possible to split validation into a checking part and an updating part?
You could do the checking outside of the transaction and not need a rollback on failure.
On dbmgr.saveData() all edited records will be validated before the actual update/insert sql is executed.
Would it help to have an option to validate the edited records using in the defined trigger methods and not actually do the save yet (a dry-run save)?
Rob
Hi Rob,
That would solve a big part of my problem, but not all.
It would not help in the following situation:
Form X using table A
- Do a new record on Form X / Table A
- Enter all fields on the screen
- BEGIN TRANSACTION
- databaseManager.saveData()
- Validate trigger on table A → ok
- INSERT statement on table A
- Insert trigger on table A
----- UPDATE statement on table B (when is the validate trigger on table B executed?)
----- Validation on B fails
- ROLLBACK TRANSACTION must be done
… but the newRecord on form X with all of the entered fields; must still be visible for the user. Only the database updates must have been rollbacked
Maybe the following is an option:
Give the databaseManager.rollbackTransaction() an optional parameter (rollbackEditedRecords), which could be default TRUE (in that case rollback works like before)
So when I do:
databaseManager.rollbackTransaction(false)
then all updates in database are rollbacked, but the edited record on the form is still visible.
In that case a separate trigger for validation is not needed, but in general, I think it is a good idea to make a validation trigger which is executed before the real database action.
Kind regards
Martin
I added the case in the support system. Wasn’t done yet.
We examined your case, but the behaviour change was really necessary, we cannot keep edited records after rollbackTx and have a consistent memory state. Servoy doesn’t know which records are valid after transaction rollback, especially when some records are successfully saved halfway of the transaction and are back in edit again upon rollbackTx.
We understand you want to keep some records containing the user input, the only solution is to use databaseManager.getChangedRecordData(…) before rollback and apply this information after the rollback on the records again.
This way you are also in full control about which information should be kept, since the edited record may also contain other records not directly related to user inputs!