We have some corrupted records, which appeared across 2 different BOs so far. We can’t delete them from the application level, and the cleanup script won’t delete them either, because they can’t be found under the IBS_SPEC table. Does anyone have a SQL to properly cleanup those records from the T_ table?
I’m loading data via the Data Integrator into a Classifications business object. In the first load, my data is successfully loaded. However, I notice some data mapping issues. So I delete the records from a query, then I clear cache. In the second load, my data is successfully loaded. I go into the Classifications hierarchy form and get the dreaded message:
“Please contact your system administrator. The tree control reported this error while trying to draw itself: There was an error in the database or the query definition.”
When this happens, I tell myself that I deleted the records too quickly and didn’t allow the system to reset in time. The solution is the dreaded wait time for the Cleanup Agent to process records that takes 12 hours, 1 day, 3 days, or sometimes 1 week, before all records with a TRIRECORDSTATESY is null, are removed from the database. The only workaround seems to be to increase the Cleanup Agent time. However, is there a sequence of steps I need to follow before I delete records from a hierarchy form, so that I don’t get the dreaded message each time?
Regarding your scenario of loading hierarchy records, deleting them, then reloading the same records to cause the tree control to fail, that should be considered a platform defect. I would advise you to enter a PMR, so Support can look into this issue. The tree control should never fail to render as you describe it.
To help with your issue, there is an unsupported platform feature that allows the Cleanup Agent to delete data immediately. If you add the following property to your TRIRIGAWEB.properties file and set CLEANUP_AGENT_RECORD_DATA_AGE=2, the Cleanup Agent when run will delete records that are 2 minutes old. This allows you to immediately delete a bad data load, and allows you to run it cleanly again a second time without conflicts from that data already existing in a null state.
[Admin: This post is related to the 08.11.16 post about the Organization hierarchy tree not being displayed, the 08.04.16 post about unretiring and returning records to null, and the 02.24.16 post about executing the Cleanup Agent (a.k.a. Platform Maintenance Scheduler) after retiring a record.]
We’re seeing the following error in the server log:
Error executingsql: Sql[SQL=TRUNCATE WF_INSTANCE,DB transaction ID=(None)] Caused by: StatementCallback; bad SQL grammar [TRUNCATE WF_INSTANCE]; nested exception is java.sql.SQLException: Incorrect syntax near 'WF_INSTANCE'. [MID-2877677308]
Error executing sql: Sql[SQL=TRUNCATE WF_INSTANCE,DB transaction ID=(None)] Caused by: StatementCallback; bad SQL grammar [TRUNCATE WF_INSTANCE]; nested exception is java.sql.SQLException: Incorrect syntax near 'WF_INSTANCE'.
When WF_INSTANCE (workflow instances) are a high number, the TRUNCATE option runs into problems in some situations. Moving forward, we resolved an issue where massive amounts of workflow instances were running into an error when cleaning them up via the Platform Maintenance Scheduler (formerly Cleanup Agent).
In one of our production instances, we have a table called TASK_RESULT_LIST containing almost one billion rows. What is the intent of that table and is there someway we can clean it up?
Anyway, when the Cleanup Agent runs, it is stopped with an Agent Interrupt Exception after 120 minutes (as per CLEAN_TIMEOUT in TRIRIGAWEB.properties). Though, it seems the Cleanup Agent doesn’t start the next day when that happens (or any following day until the process server is restarted). Is there some flag saying that the agent is already running and that flag is not getting reset when the agent is stopped due to hitting the CLEAN_TIMEOUT?
That TASK_RESULT_LIST is used to record workflow step instances. It is not safe to directly modify the table. The Cleanup Agent (a.k.a. Platform Maintenance Agent) is supposed to keep this table clean. Check the following TRIRIGAWEB.properties…
To help work around this, I would set the CLEAN_TIMEOUT property to 300. This will allow the Platform Maintenance Agent to run for a longer amount of time and clean up more records. The reason the table got so large, is that you had workflow instance recording on. Our recommendation is that workflow instance recording is never run in production, or for long periods of time. It is also not safe to truncate that table, as user action and approval tasks would be deleted and would no longer process. We also increased the default value of CLEAN_TIMEOUT to 300 in our next release…
Scheduled events are not being removed by the Cleanup Agent from the table T_SCHEDULEDEVENTS after the scheduled events are completed. This causes this table to grow immensely, especially for companies that use recurrence events in their calendar. Identifying the records can be done via SQL…
The deletion of these records are currently not automated by the Cleanup Agent.
Moving forward, the completed scheduled events older than the value specified in the property CLEANUP_AGENT_SCHEDULED_EVENT_COMPLETE_DAYS will
now be marked for deletion.
We are experiencing an issue where associations seem to be recreated after the Cleanup Agent has run, and I wondered if anyone else had experienced this before?
On a Capital Project template, we have associated some Work Task and Schedule Task templates, and these are successfully showing up in the query section on the Schedule tab of the Capital Project template. We have a Remove action on the query section, which, when we select a Task template and click remove it, de-associates the record from the Capital Project template. We have verified that the associations are deleted and the record disappears from the query section. However, after the Cleanup Agent runs, these removed task templates are reappearing in the query section of the Capital Project template and the associations have been recreated.
Is anyone aware of this behaviour, or of something in the Cleanup Agent that might be recreating these associations? If so, is there a way around it as users are starting to complain that records they have removed are showing back up again?