Hi Everyone,

We have a row producing procedure which works perfectly well most of
the time - don't you love it - but every now and then it fails and we get
the following fairly unhelpful messages in the errlog.
INHARP_C::[34419 , 0d2609a0]: Mon Sep 19 15:07:28 2005
E_SC0216_QEF_ERROR Error returned by QEF.
INHARP_C::[34419 , 0d2609a0]: Mon Sep 19 15:07:28 2005
E_SC0206_CANNOT_PROCESS An internal error prevents further
processing of this query. Associated error messages which provide
more detailed information about the problem can be found in the error
log, II_CONFIG:errlog.log
INHARP_C::[34419 , 0d2609a0]: Query: Execute Procedure
get_assoc_staff
INHARP_C::[34419 , 0d2609a0]: LQuery: select
param_sequence, param_name, procedure_owner, user_name,
dba_name, system_owner from iiproc_params, iidbconstants where
procedure_name = ~V and (procedure_owner = user_name or
procedure_owner = dba_name or procedure_owner = system_owner)
order by param_sequence^@

The procedure is fairly simple. So much so that it doesn't have any
error checking embedded in it. It examines a few simple tables and
would normally return something in the order of 1000 integers.

Anyone got any ideas what might be happening?

Martin Bowes
--
Random Duckman Quote #102:
Cornfed: Uh Oh.
Duckman: 'Uh Oh' as in 'Nice Work?'
Cornfed: No, as in 'You're screwed.'

At 11:27 AM +0100 9/23/05, martin.bowes (AT) ctsu (DOT) ox.ac.uk wrote:
It's hard to be sure at a distance, but this looks a lot like a bug
that I fixed in r3 very recently.

Row-producing procedures violate some of the original sequencer assumptions,
so they were tricky to get right. If the RPP is booted out of the QSF
cache at an inopportune time, weird things like your SC0216 error
can occur. You can also get garbled rows back, although that's a bit
harder to cause. (For that one to happen, the RPP has to generate some
output and then cause a rule to fire that's not in QSF.)

I don't know that there is any real workaround, although you might try
increasing the size of QSF memory just to see if that helps.

If you're running 2.6, you'll have to open an issue and see if you can
sucker one of the L2 engineers into trying to back-port the fixes. :-)

Karl

Hi Karl,

Sounds about right. Yes we are running this on 2.6.

I've counter checked the number of occurrences we've actually
had - 4. So I might try the qsf memory hint first before I head off and
annoy someone in L2.

Actually this could be a good reason to recommend to this
project that they consider the upgrade to R3. They also have a nasty
habit of making views of views of views and end up with 30 tables
involved in a join. R3 should help tremendously there as well.

Marty

On 23 Sep 2005 at 6:53, Betty & Karl Schendel wrote: