Re: [Info-ingres] Row producing procedure errors

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:

> At 11:27 AM +0100 9/23/05, martin.bowes@xxxxxxxxxxxxx wrote:
> >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
>
> 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
> _______________________________________________
> Info-ingres mailing list
> Info-ingres@xxxxxxxxxxxxxxx
> http://mailman.cariboulake.com/mailman/listinfo.py/info-ingres
>


.