This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Problem with re-calculation logic

Hi community and M-Files,

I have a trouble with some re-calculation. We have quite a specific logic, with some calculation in pre-condition, state action of the state. But as well certain calculations in MFEventHandlerBeforeCheckInChangesFinalize event.

I use always Vault.ObjectPropertyOperations.SetLastModificationInfoAdmin to retain history and information about user making changes. 

However when the execution happens in one specific case, I am getting an error:

"The maximum number of script executions permitted during a single operation was exceeded for the object "

What happens is following:

1. State pre-condition runs with calculations and SetLastModificationInfoAdmin is called

2. State action is called with calculations and SetLastModificationInfoAdmin is called

3. CheckIn Event is called with re-calculation and SetLastModificationInfoAdmin is called

If I remove SetLastModificationInfoAdmin  in case 2), it works. However, sometimes there are no changes catched in checkIn event and then history is broken with entry for M-Files Server as the re-calculation is not running.

Code is very optimized and I only run SetLastModificationInfoAdmin if something is effectively changed.

Unfortunately, I can not correlate between event and state.

Is there any option to increase the maximum of script executions?

Best,

Dejan

  • You can increase the limit in Advanced Vault Settings, Scripting.

  • I would be wary about increasing the limit.  Have you logged out what's happening?  Is it perhaps caught in some kind of loop?  Are the events themselves causing some sort of cascade of check-out/check-in events for the current object?

    Also, and I know that this perhaps doesn't help with the specific issue here, I personally am wary of state pre-conditions that alter objects.  I have no official guidance here, but I've just not felt right doing it.  Is there a reason why the logic is there and not in the state itself (I can think of a good one, but I want to know what your thoughts are)?

  • Thanks Karl. I will keep this one into consideration. 

  • Hi Craig, 

    I agree with you. I have also hesitated to increase this limit. I've fixed it currently by checking the state and applying last modified admin method in that case. So no need for script execution number increase.

    Generally, I have followed up the practice to apply last modified admin method every time metadata got changed (usually at the end of pre-condition, state action or event). Generally, the biggest problem is that events are not correlated and it is needed to protect yourself of re-calculating logic which can be very excessive. Also, it is for me not always clear where one transaction ends and another starts.

    Why pre-condition calculation in this case: we have some e-mails where we need full names of people initiating the action, so we calculate name in pre-condition and then send an e-mail in workflow state. During state action, we have then more heavier calculations (when needed).

    Best,

    Dejan

  • Hi Dejan,

    I'm still not sure why you need the pre-condition though.  Is the email being created by script?  Why not calculate the name inside the same workflow state that you send the email from?

    Your general approach is correct (to update last-modified every time your script updates an object, assuming the current user ID is not < 0).

    It does sound like there's some sort of cascade happening (one update causes another script to run, which causes another script to run, which causes...).  Are you sure that's not the case?

    Craig.

  • At the end, I had to increase scripting config (first one) from 25 to 30. But somehow on our dev/test environment I miss "Scripting" option in Advanced Vault Settings. We have there exact the same version. Do you know if there is some registry settings to enable those. Perhaps I forgot what we changed there. Thanks!