[Info-ingres] E_QE0018 before trigger got weird!

[Martin Bowes]

Agh... And when you check the errlog you see that the its bitching with errors related to row level locking.

    For Ingres 11 the errlog will also show:
    E_DM93F5_ROW_LOCK_PROTOCOL
    E_DM925F_DM1B_GETBYBID
    E_DM008C_ERROR_REPLACING_RECORD
    E_QE007E_ERROR_REPLACING_RECORD

    For Ingres 10 the errlog will also show:
    E_DM93F5_ROW_LOCK_PROTOCOL
    E_QE0018_BAD_PARAM_IN_CB

This is strange as I had not requested any row level locking. But my test case uses a page_size of 8192 for both the base table and its archive.

I altered the test to use a 2048 page and ... the problem went away.

So in order to keep an archive table for a table with long objects I now will have a 3 step workaround.

Keep on dancin' Maria.

I think I'll raise a bug on this.

Marty


From: Martin Bowes [mailto:martin.bowes at ndph.ox.ac.uk]
Sent: 26 June 2018 10:59
To: info-ingres at lists.planetingres.org
Subject: [Info-ingres] E_QE0018 before trigger got weird!

Hi All,

On Ingres 10.2/11 etc...

I have a before triggered rule which I am sure used to work but now is throwing  E_QE0018 Illegal parameter in control block.

As a little background:
The table has a long varchar column.
We got around the restriction on longs being passed in an AFTER trigger by using the BEFORE trigger.
We then got around the before triggered procedure not being able to update data by getting it to call a second procedure which achieved the insert into the archive table.

All of that workaround chain is working fine...seriously!

And the problem is:
If the final procedure attempts to update a non long column in the original table then we see:

E_QE0018 Illegal parameter in control block.

Note that the column being updated in the table has been excluded from the action of the rule.

Furthermore, this happens even if the table contains no long objects.

If the final procedure updates another table rather than the original table then the procedure is fine.

If people want to play with this I've attached a rudimentary test case.

Do E_QE0018.sh -help and then follow the bouncing ball.

Marty

PS.
Of course the actual table which has the long data has no element longer than 379 characters.
The owners are convinced that in the fullness of time someone will put a genuinely long piece of data in there.
The table has been in existence since 24/12/2015.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.planetingres.org/pipermail/info-ingres/attachments/20180626/175a04c6/attachment.html>