Cursor sensitivity has been around since early ASE 15.x (not sure if it was ASE 15.0, or 15.0.x).
Without more details about *HOW* the cursors are defined I'm going to assume:
- UPDATE/DELETE statements do not include the clause 'where current of <cursor_name>'
- cursor is not defined as 'read only'
- cursor is instantiated as semisensitive (this is the default setting if no sensitivity clause provided in the 'declare cursor' command)
- while the cursor is open, any changes to the underlying data causes the cursor result set to change, which in turn can cause cursor to abort/break if it tries to fetch a row that has now changed/moved within the result set
If the above describes your situation then I'd recommend making the following changes to your cursor declaration statement:
- define as insensitive (declare <cursor_name> insensitive cursor for ...); this causes the cursor to populate a worktable with the cursor's SELECT statement results; the cursor then fetches from the worktable thus insuring that changes to the underlying table(s) does not affect the cursor's result set
- define with 'for read only'
NOTE: These are T-SQL (ie, server-side) recommendations; if you're using client-side cursors you'll need to figure out how to make similar changes on the client-side (eg, see client-side coding reference manuals, wait for a client-side knowledgeable person to respond in this thread)