Open Cursor for Cache error

kread

Active Member
I'm interfacing to JDE 9.1 from dcLink (DSI). We're kicking off P31123 through an API call to perform a super backflush. It's returning "Open Cusror for cache failed. We're only receiving this for one work order. I've read some history on this issue but don't see anything that's recent.

We have our processing options set up in a version but otherwise, we're using the base object P31123.

I'm not the CNC but would we have a cache setting that I need to check?

Thanks,
Kelly
 
If you are getting this error it is almost certainly a bug some place in the code. It may be expecting records to be in cache and for what ever reason they are not or there is a jdeCache cursor leak.

The bug may be manifesting itself due to an unexpected state of the data. In other words you might be able to change some business data or setup/constants in the mfg. module and get past the problem, but ultimately there is a bug in the code some place, either in DSI's code or in the JDE pristine code.
 
When you say you're kicking off P31123, what exactly do you mean?

Are you calling the DSI super backflush NER to perform the action? If so, are you calling it in such a way as to perform the entire backflush in one API call or are you calling it so it caches up each operation sequence and then you call it at the end to perform the EndDoc?

It is possible, however unlikely, that subsequent calls via the DSI connector could 'lose' the link to the original call object kernel and the next DSI call (within the same transaction) could be run in an entirely different kernel which would render all prior caching useless. I always call the DSI functions with an action code to perform the entire unit-of-work in one call.

I tend to think this is not your issue especially it this only happens on one specific WO. Are you able to duplicate this when trying to process this WO from a base jde P31123 screen? Hopefully you are..which means you may be in for some c-debugging to figure what's happening.

Good luck and let us know what you find.
 
I recently saw this error and when going through the call object kernel logs I found that DSI was referencing a version of P31123 that did not exist in that environment. Once that was fixed the errors went away
 
Back
Top