Expected NUMBER got DATE - sql

Question

I am getting an SQL error that makes no sense to me. I created a table called SUBORDER using this command:
CREATE TABLE SUBORDER (
OrderNo int,
SuborderNo int,
ReqShipDate date,
ActualShipDate date,
BranchName varchar(50),
primary key (OrderNo, SuborderNo),
foreign key (OrderNo) references ORDERS(OrderNo) on delete set null,
foreign key (BranchName) references BRANCH(BranchName) on delete set null
);
As you can see, ReqShipDate and ActualShipDate were declared as dates. But then when I run this code:
create or replace trigger shipment_late
before update
on SUBORDER
for each row
declare
reqdate DATE;
actualdate DATE;
begin
select s.ReqShipDate, s.ActualShipDate into reqdate, actualdate
from SUBORDER s
where ( s.OrderNo = :new.OrderNo ) and ( s.SuborderNo = :new.SuborderNo );
if reqdate > actualdate then
insert into LATE_SHIPMENT
select * from SUBORDER s
where ( s.OrderNo = :new.OrderNo ) and ( s.SuborderNo = :new.SuborderNo );
end if;
end;
the SQL console tells me:
Error(12,11): PL/SQL: ORA-00932: inconsistent datatypes: expected
NUMBER got DATE
Why is it expecting a number?

Answer 1

It appears that you just want
create or replace trigger shipment_late
before update
on SUBORDER
for each row
begin
if :new.ReqShipDate > :new.ActualShipDate
then
insert into LATE_SHIPMENT( <<list of columns>> )
values( :new.OrderNo, :new.SuborderNo, ... );
end if;
end;
A couple things to be aware of
It's always a good idea to explicitly list out the columns if you're doing an insert statement. Otherwise, you're relying on an implicit order that isn't going to be obvious to someone reading your code and that creates quite a bit of potential for errors. Listing out the columns, at a minimum, documents what values you are putting where. In this example, it seems unlikely that the late_shipment table has exactly the same set of columns in suborder defined in exactly the same order.
In general, a row-level trigger on a table (SubOrder in this case) cannot query that table. Doing so will generally raise a mutating table exception. That doesn't appear to be necessary here, however. You just need to reference the various attributes of the :new pseudo-record.