A lot of "Process Management Change Case did not receive an ID" log appearing ...

Hi Enes Saridogan,

Thank you for asking this question.

This challenge is correlated to Issue 85751. This Issue will be fixed in 13.0.0

When this symptom occurs, this query to find out which process is orphaning flow rows:
SELECT pro_id a, count(*) b FROM `pmse_bpm_flow` where cas_id is null GROUP BY a ORDER BY b DESC;

This query to delete them:
DELETE FROM `pmse_bpm_flow` where cas_id is null;

The processes associated with the results should be reviewed. If you would like assistance reviewing them, I recommend filing a support case and our team can help you further.

Regards,
Patrick McQueen
Director, SugarCRM Support

Hello Patrick McQueen,

Thanks for the feedback. I just ran the query on the database and we have more than 21 millions of orphan records : 

I think the hard delete like you wrote would cause me a timeout, I have to be more specific I think, or find another approach.

pmse_inbox and pmse_bpm_flow are more thant 65Gb gross :/

Hello Patrick McQueen,

Thanks for the feedback. I just ran the query on the database and we have more than 21 millions of orphan records : 

I think the hard delete like you wrote would cause me a timeout, I have to be more specific I think, or find another approach.

pmse_inbox and pmse_bpm_flow are more thant 65Gb gross :/

Hi Enes,

To mass delete at a scale like this, I instead create a temp table like the original, move to the temp all the rows I wish to keep, and then swap them out.

CREATE TABLE pmse_bpm_flow_cleaned LIKE pmse_bpm_flow; INSERT INTO pmse_bpm_flow_cleaned SELECT * FROM pmse_bpm_flow WHERE pmse_bpm_flow.cas_id IS NOT NULL;

RENAME TABLE pmse_bpm_flow TO pmse_bpm_flow_backup, pmse_bpm_flow_cleaned TO pmse_bpm_flow;

I also strongly recommend assessing that top process definition for a more pragmatic approach to what it is doing for you and when it does it because it looks like it runs a remarkable amount.

Regards,
Patrick McQueen
Director, SugarCRM Support