Unexpected "ORA-01001: invalid cursor" error

Question

I have a Pro*C application that basically fetches from a cursor, does a bunch of work with that row, does a "delete from <table> where current of <cursor name>", then loops back, fetches, the next row, etc., and finally closes the cursor once all the rows have been processed.
One of our clients is getting an 'ORA-01001' error on the "DELETE FROM <table> WHERE CURRENT OF <cursor>" statement. This is long-standing, frequently executed code at 100+ clients and I've never had a problem with this statement before. The client is consistently getting this error on a particular row from this cursor, but other rows processed with the same cursor are processing successfully.
Unfortunately, I do not have direct access to the client's database, so I cannot debug directly, but I've placed print statements around the only place in my application's code that explicitly closes the cursor. A log generated on a run that threw the 1001 error confirmed that the cursor is NOT being explicitly closed by my application by an "EXEC SQL CLOSE <cursor>" statement.
Likewise, I put print statements around all the COMMITs and ROLLBACKs in my application, and none of these showed in the logs either.
My application does make a call to a client-customized PL/SQL function that they recently changed. However, I have a copy of the clients function and there are not any explicit COMMIT, ROLLBACK, ANALYZE, ALTER, DROP, REPLACE, TRUNCATE or CREATE statements that would implicitly commit and close the cursor.
Here are potential problems that I have ruled out:
-Oracle OPEN_CURSORS parameter - It appears that if this were the problem, the error would be an ORA-1000, not 1001. Please correct me if I am wrong here.
-Pro*C MAXOPENCURSORS parameter - I compiled a version with a MAXOPENCURSORS value that is higher than the client's OPEN_CURSORS setting. If this were the problem, the error should have switched to the ORA-1000 error when I increased the parameter. It remained as an ORA-1001.
Next steps:
-What could cause a cursor to close other than explicit COMMIT, ROLLBACK, ANALYZE, ALTER, DROP, REPLACE, TRUNCATE or CREATE statements?
-Is there anything I can run, such as a database trace, that will show me exactly when the cursor is being closed? I admittedly don't know a lot about DB traces.
-Anything else I should check? Any other information I should provide?
Thanks ahead of time for any help!

Answer 1

Chandrakaanth Ramamurthy wrote:
Does the client customized PL/SQL block contain EXIT
Exit will end up issuing a commit and hence this could be an issue.Exit is not used in the customized function.
Chandrakaanth Ramamurthy wrote:
Also please check that commit and roll back are placed at the end of the loop.The only commit/rollback is after the loop is over is finished.
I actually just figured out the issue. Turns out the cursor just hadn't been opened due to a very unique data condition... facepalm You know what happens when you assume things, right? :)
Thanks for the help anyway!