#GeneralInterest -: Hi all , I have one scenario, Let say i have one table

I wouldn't like to really agree with the statement 'It is always good to have DB Interactions in a sub-process and configuring a exception timer on the sub-process in case the insertion or updation fails.' and it completely depends on the scenario and the design. I believe that the design as mentioned above is not completely fool proof and the process need to run on an assumption that it fails in one and only one case.

For instance, let's take a case where the Write to Database node has failed because of the reasons other than the Unique Constraint Violation Exception while updating a particular record. Also let's assume that the node has failed while trying to insert data into a column of more than its length or trying to insert a in-existent key when a foreign key is expected. It might not really make sense if the process takes exception path in these cases without resolving the issue and in-fact that might create new issues.


And with regards to update operation, again I wouldn't like to completely agree with the statement that we don't need to do anything because it depends on what you desire for. So if you are looking forward to make an update and also make the operation safe from concurrent updates, then I would suggest going through the documentation at forum.appian.com/.../Data_Locking_Strategies.html. And @stefanh in his previous comments has pointed to a link where you can see some good comments made by him and other practitioners. I suggest taking a call post analysing all the available options and also after analysing the scenarios and running through the assumptions.

I wouldn't like to really agree with the statement 'It is always good to have DB Interactions in a sub-process and configuring a exception timer on the sub-process in case the insertion or updation fails.' and it completely depends on the scenario and the design. I believe that the design as mentioned above is not completely fool proof and the process need to run on an assumption that it fails in one and only one case.

For instance, let's take a case where the Write to Database node has failed because of the reasons other than the Unique Constraint Violation Exception while updating a particular record. Also let's assume that the node has failed while trying to insert data into a column of more than its length or trying to insert a in-existent key when a foreign key is expected. It might not really make sense if the process takes exception path in these cases without resolving the issue and in-fact that might create new issues.


And with regards to update operation, again I wouldn't like to completely agree with the statement that we don't need to do anything because it depends on what you desire for. So if you are looking forward to make an update and also make the operation safe from concurrent updates, then I would suggest going through the documentation at forum.appian.com/.../Data_Locking_Strategies.html. And @stefanh in his previous comments has pointed to a link where you can see some good comments made by him and other practitioners. I suggest taking a call post analysing all the available options and also after analysing the scenarios and running through the assumptions.