Hi All,

Leaving aside the sense of passing a long object in the parameter list of aprocedure....

In Ingres 9.2 we could pass a long object as a procedure parameter and thiswas cool in both insert and update fired rules.

But in Ingres 10 the insert fired rule is OK with passing the long, but an update fired rule will fail and generate error:
E_QE011D Error converting value for the database procedure parameter
'new_string'. A peripheral object parameter is associated with an EXECUTE
PROCEDURE statement or database rule invocation. Please see errlog.log
for more information.

Try this....
sql bowtest << SQL_END
set autocommit on
\g
drop table x;
\p\g
drop table archive_x;
\p\g
drop procedure x_iu_proc;
\p\g
create table x (
id integer not null not default,
a integer not null not default,
string long varchar not null not default
) with nojournaling;
modify x to btree unique on id;
\p\g
create table archive_x (
id integer not null not default,
a integer not null not default,
string long varchar not null not default,
a_date ingresdate not null with default 'now'
) with nojournaling;
\p\g
create procedure x_iu_proc(
new_id integer not null,
new_a integer not null,
new_string long varchar not null
) as
begin
insert into archive_x (id, a, string, a_date)
values (new_id, new_a, new_string, 'now');
end;
\p\g
create rule x_iu_rule
after insert, update of x
for each row
execute procedure x_iu_proc(
new_id = new.id, new_a = new.a, new_string = new.string
);
\p\g
/* These inserts will be OK */
insert into x (id, a, string) values (0, 0, 'zero');
\p\g
insert into x (id, a, string) values (1, 1, 'one');
\p\g
/* If the bug is present then these updates will generate E_EQ011D */
update x set a = a + 1 where id = 1;
\p\g
update x set string = string + ' and this bit' where id = 0;
\p\g
\q
SQL_END

On Mar 3, 2011, at 4:42 AM, Martin Bowes wrote:

Anything interesting in the DBMS log? (II_DBMS_LOG)

QE011D happens when a move from a dbproc parameter into
the dbproc local fails. For a blob, it's calling adu_lvch_move,
which in turn calls dmpe with ADP_COPY, and dmpe isn't
having any of it. This sounds a bit like a bug.

Does the update fail if there's only ONE row in the table?

Karl

Hi Karl,

We get the error if there is only a single row in the table.

In the dbms log we see.
E_AD700B_BAD_POP_CB An invalid peripheral operations control block was passed.
E_AD700B_BAD_POP_CB An invalid peripheral operations control block was passed.
E_AD7009_ADP_MOVE_FAILURE An error was encountered performing an ADP_MOVE operation on a peripheral datatype.

I've also experimented with blob_etab_page_size. Same result with 2k, 4k and 8k pages.

I've raised it with IngresCorp.

Marty

-----Original Message-----
From: Karl Schendel [mailto:schendel (AT) kbcomputer (DOT) com]
Sent: 03 March 2011 14:53
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] Ingres 10 Update fire rule and longs


On Mar 3, 2011, at 4:42 AM, Martin Bowes wrote:

Anything interesting in the DBMS log? (II_DBMS_LOG)

QE011D happens when a move from a dbproc parameter into
the dbproc local fails. For a blob, it's calling adu_lvch_move,
which in turn calls dmpe with ADP_COPY, and dmpe isn't
having any of it. This sounds a bit like a bug.

Does the update fail if there's only ONE row in the table?

Karl



_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres