Alan Burlison wrote:
>> Bug, or pilot error?
>
> A bit of both I suspect - I was updating the table twice without a
> commit in between. Adding a commit seems to have solved it.
Spoke too soon, it's baaaaaaack! Looks a bit like
http://issues.apache.org/jira/browse/DERBY-388, albeit with a different
stack trace.
I've recoded the update logic to remove the triggers and perform the
processing the triggers did in my program, and the problem goes away.
Here's the scenario:
create table member (
member_id integer not null generated by default as identity,
member_name varchar(32) not null,
real_name varchar(50) not null,
email varchar(50) not null,
:
lc_member_name varchar(20),
lc_real_name varchar(50),
lc_email varchar(50),
:
);
create trigger m__mn__it after insert on member
for each row update member set lc_member_name = lower(member_name);
create trigger m__mn__ut after update of member_name on member
for each row update member set lc_member_name = lower(member_name);
create trigger m__rn__it after insert on member
for each row update member set lc_real_name = lower(real_name);
create trigger m__rn__ut after update of real_name on member
for each row update member set lc_real_name = lower(real_name);
create trigger m__e__it after insert on member
for each row update member set lc_email = lower(email);
create trigger m__e__ut after update of email on member
for each row update member set lc_email = lower(email);
I haven't had time to create a cut-down test case, but from the stack
trace I sent earlier it looks to be related to the use of triggers, and
the fact that the problem goes away when I remove the triggers and do
the processing 'by hand' seems to confirm that.
--
Alan Burlison
--
|