We haven’t seen enough of these incidents to fully explain why this error appears, but they usually resolve themselves. Here’s a possible reason:
Non-Technical Explanation
During the rate uplift for this element type, another element type with a rate change that evening might have been processed first. This prior element type used a database object to update suspension information based on the new rate and didn’t return it to the system after finishing its uplift. So, when the next element type tries to use this object, it finds it already in use, causing the error.
This might resolve itself in the next evening’s overnight jobs, but if it doesn’t, please raise a new case online and reference the title of this article with the details mentioned at the end of the solution.
Technical Explanation
For a bit more technical detail, we’ll illustrate this with an example element type being uplifted called 'Supported Living (1:1 hourly).'
When you uplift this element type, you may see an error message that reads: ‘STEP: update rate susp; p_db_message: ERROR: 16915 A cursor with the name 'c_elem_susp' already exists. at line 44 in update_rates_susp Step: Suspension vars at new rate Rate_change_id: [your specific ID]’
During this process, Apply_Changed_Rates collects all new rate changes for various element types and stores them in a cursor called cur_rate_changes. It then loops through each element type’s rate change one by one.
The procedure update_rates_susp updates commitments with suspensions for the Supported Living (1:1 hourly) element type. First, it gathers all commitments that might need updating and are in a suspended state. It then attempts loads these into a cursor named c_elem_susp and loops through each candidate to ensure their suspensions are correct.
The error indicates that ‘A cursor with the name c_elem_susp already exists,’ suggesting that a previous element type’s rate change from the cur_rate_changes cursor also declared the c_elem_susp cursor but didn’t close and deallocate it.
As a result, when the Supported Living (1:1 hourly) element type needed to declare its own c_elem_susp cursor, it encountered the existing one in memory. This should’ve been closed at the end of the previous element type’s loop.
It’s possible that during other rate uplifts, another element type managed to deallocate and close the c_elem_susp cursor, or some refresh occurred, allowing the rate to apply correctly the next evening. It seems there was nothing inherently wrong with the rate setup for that element; rather, the cursor wasn’t properly managed during the previous rate uplift.
If it’s still erroring, then please raise a new case online and reference the title of this article with the following:
Screenshot of the element type showing the error.
A screenshot of the full rate change box and the full error message beside it.
Directions on how to navigate to that exact element type so we can further investigate.