OnAfterUpdate/Insert/Delete triggers and business logic
Posted: Wed Feb 10, 2016 6:54 pm
Hello,
I'm using dbEvents to update the status of some related records based on the main record status. Basically, when the option in the main record is disabled, I want this option to be disabled on some related records, on another table on another server. I'm currently using this kind of structured event in many place in our solutions ( new client folder created on the server when a new client is inserted, etc )
Actually, this is done through the onAfterRecordUpdate(), when the client status is changed and saved calling the onRecordUpdate() trigger, which purpose, in my mind was purely and strictly to validate the records changes ( "can we set this client option to "No", based on some business logic ).
But when an error happens in the onRecordAfterUpdate() - record locking or any other error occuring during one save process in the related set - there's no way to rollback the transaction to revert the main record option to what it was, even though everything started with a startTransaction(). The onRecordAfterUpdate() has a try/catch/finally structure and the errors are correctly reported back to the user so that he knows that something went wrong, but then he still has related records with some invalid status.
I saw in another thread that I can now do this inside the onRecordInsert() trigger, which for sure does the job, from several tests I did, as the main record itself is not saved if any error occurred during the related records updates.
I started thinking of changing my logic, but then, I'm wondering what is finally the purpose of the onRecordAfterUpdate/Insert/Delete if everything can now be done during the onRecordInsert/onRecordUpdate process.
As a matter of fact, some tables are shared by several applications with some separate business logic, we handle several onRecordInsert/onRecordUpdate in separate scopes, each being called to control their respective business rules ( ex : trigger in scopeA controls that client data is in synch with our servoy CRM, trigger in scopeB controls that the client parameters are valid for our Content Management solution, and trigger in scopeC checks that the options are valid in the servoy Project Management application he is using as a SaaS service.
My onAfterRecordInsert/Update/Delete are therefore called only when all on RecordInsert/Update/Delete have been succesfully triggered. As this is currently organized, I'm a bit lost if triggering these "after" logics in the "before" process.
Any idea ?
Thanks
Ugo
I'm using dbEvents to update the status of some related records based on the main record status. Basically, when the option in the main record is disabled, I want this option to be disabled on some related records, on another table on another server. I'm currently using this kind of structured event in many place in our solutions ( new client folder created on the server when a new client is inserted, etc )
Actually, this is done through the onAfterRecordUpdate(), when the client status is changed and saved calling the onRecordUpdate() trigger, which purpose, in my mind was purely and strictly to validate the records changes ( "can we set this client option to "No", based on some business logic ).
But when an error happens in the onRecordAfterUpdate() - record locking or any other error occuring during one save process in the related set - there's no way to rollback the transaction to revert the main record option to what it was, even though everything started with a startTransaction(). The onRecordAfterUpdate() has a try/catch/finally structure and the errors are correctly reported back to the user so that he knows that something went wrong, but then he still has related records with some invalid status.
I saw in another thread that I can now do this inside the onRecordInsert() trigger, which for sure does the job, from several tests I did, as the main record itself is not saved if any error occurred during the related records updates.
I started thinking of changing my logic, but then, I'm wondering what is finally the purpose of the onRecordAfterUpdate/Insert/Delete if everything can now be done during the onRecordInsert/onRecordUpdate process.
As a matter of fact, some tables are shared by several applications with some separate business logic, we handle several onRecordInsert/onRecordUpdate in separate scopes, each being called to control their respective business rules ( ex : trigger in scopeA controls that client data is in synch with our servoy CRM, trigger in scopeB controls that the client parameters are valid for our Content Management solution, and trigger in scopeC checks that the options are valid in the servoy Project Management application he is using as a SaaS service.
My onAfterRecordInsert/Update/Delete are therefore called only when all on RecordInsert/Update/Delete have been succesfully triggered. As this is currently organized, I'm a bit lost if triggering these "after" logics in the "before" process.
Any idea ?
Thanks
Ugo