
|
If you were logged in you would be able to see more operations.
|
|
|
| Planning Status: |
Unspecified
|
|
Changing data that affects an expression index that contains references to null date fields fails in Firebird 2.5
Here is an isql script to show the effect:
-------
create database 'bugtest.fdb';
show version;
CREATE GENERATOR GEN_POLICEN_ORDER_ID;
CREATE TABLE POLICEN_ORDER (
ID INTEGER NOT NULL,
VSTATUS INTEGER,
ABLAUF DATE,
VSTORNO INTEGER,
STORNO DATE
);
ALTER TABLE POLICEN_ORDER ADD CONSTRAINT PK_NEW_TABLE PRIMARY KEY (ID);
SET TERM ^ ;
CREATE OR ALTER TRIGGER POLICEN_ORDER_BI FOR POLICEN_ORDER
ACTIVE BEFORE INSERT POSITION 0
as
begin
if (new.id is null) then
new.id = gen_id(gen_policen_order_id,1);
end
^
SET TERM ; ^
-- insert some data with null dates
INSERT INTO POLICEN_ORDER (ID, VSTATUS, ABLAUF, VSTORNO, STORNO)
VALUES (2, 1, NULL, NULL, NULL);
INSERT INTO POLICEN_ORDER (ID, VSTATUS, ABLAUF, VSTORNO, STORNO)
VALUES (3, 2, NULL, NULL, NULL);
INSERT INTO POLICEN_ORDER (ID, VSTATUS, ABLAUF, VSTORNO, STORNO)
VALUES (4, 3, NULL, NULL, NULL);
COMMIT;
-- now let's create an obscure index
CREATE INDEX IDX_POLICEN_ORDER_BIT_VSTATUS ON POLICEN_ORDER COMPUTED BY (case
when POLICEN_ORDER.VSTATUS=1 then 64 -- Anbahnung
when POLICEN_ORDER.VSTATUS=7 then 32 -- DA
when POLICEN_ORDER.VSTATUS=8 then 16 -- Angebot
when POLICEN_ORDER.VSTATUS=0 then 8 -- Vertrag
when POLICEN_ORDER.VSTATUS=3 then 8 -- Vertrag
when POLICEN_ORDER.VSTATUS=4 then 8 -- Vertrag
when POLICEN_ORDER.VSTATUS=5 then 8 -- Vertrag
when POLICEN_ORDER.VSTATUS=6 then 8 -- Vertrag
when POLICEN_ORDER.VSTATUS=2 then 4 -- Fremdvertrag
else 0
end +
case when coalesce(POLICEN_ORDER.ABLAUF, current_date+1)<=current_date or
POLICEN_ORDER.VSTORNO=1 and coalesce(POLICEN_ORDER.STORNO,
current_date+1)<=current_date then 2 else 0 end);
-- and do some work with the data that will fail miserably in 2.5
update POLICEN_ORDER
set VSTATUS = 8
where (ID = 2);
commit;
-- this works in 2.0
select * from policen_order;
update POLICEN_ORDER
set VSTATUS = 2
where (ID = 2);
commit;
exit;
--------
Here is what happens in 2.0:
-------
....
update POLICEN_ORDER
set VSTATUS = 8
where (ID = 2);
commit;
-- this works in 2.0
select * from policen_order;
ID VSTATUS ABLAUF VSTORNO STORNO
============ ============ =========== ============ ===========
2 8 <null> <null> <null>
3 2 <null> <null> <null>
4 3 <null> <null> <null>
-----
and this is from 2.5
------
.....
update POLICEN_ORDER
set VSTATUS = 8
where (ID = 2);
Statement failed, SQLSTATE = 22008
value exceeds the range for valid dates
After line 52 in file bugtest.sql
commit;
-- this works in 2.1
select * from policen_order;
ID VSTATUS ABLAUF VSTORNO STORNO
============ ============ =========== ============ ===========
2 1 <null> <null> <null>
3 2 <null> <null> <null>
4 3 <null> <null> <null>
update POLICEN_ORDER
set VSTATUS = 2
where (ID = 2);
Statement failed, SQLSTATE = 22008
value exceeds the range for valid dates
After line 62 in file bugtest.sql
commit;
exit;
hth
fsg
|
|
Description
|
Changing data that affects an expression index that contains references to null date fields fails in Firebird 2.5
Here is an isql script to show the effect:
-------
create database 'bugtest.fdb';
show version;
CREATE GENERATOR GEN_POLICEN_ORDER_ID;
CREATE TABLE POLICEN_ORDER (
ID INTEGER NOT NULL,
VSTATUS INTEGER,
ABLAUF DATE,
VSTORNO INTEGER,
STORNO DATE
);
ALTER TABLE POLICEN_ORDER ADD CONSTRAINT PK_NEW_TABLE PRIMARY KEY (ID);
SET TERM ^ ;
CREATE OR ALTER TRIGGER POLICEN_ORDER_BI FOR POLICEN_ORDER
ACTIVE BEFORE INSERT POSITION 0
as
begin
if (new.id is null) then
new.id = gen_id(gen_policen_order_id,1);
end
^
SET TERM ; ^
-- insert some data with null dates
INSERT INTO POLICEN_ORDER (ID, VSTATUS, ABLAUF, VSTORNO, STORNO)
VALUES (2, 1, NULL, NULL, NULL);
INSERT INTO POLICEN_ORDER (ID, VSTATUS, ABLAUF, VSTORNO, STORNO)
VALUES (3, 2, NULL, NULL, NULL);
INSERT INTO POLICEN_ORDER (ID, VSTATUS, ABLAUF, VSTORNO, STORNO)
VALUES (4, 3, NULL, NULL, NULL);
COMMIT;
-- now let's create an obscure index
CREATE INDEX IDX_POLICEN_ORDER_BIT_VSTATUS ON POLICEN_ORDER COMPUTED BY (case
when POLICEN_ORDER.VSTATUS=1 then 64 -- Anbahnung
when POLICEN_ORDER.VSTATUS=7 then 32 -- DA
when POLICEN_ORDER.VSTATUS=8 then 16 -- Angebot
when POLICEN_ORDER.VSTATUS=0 then 8 -- Vertrag
when POLICEN_ORDER.VSTATUS=3 then 8 -- Vertrag
when POLICEN_ORDER.VSTATUS=4 then 8 -- Vertrag
when POLICEN_ORDER.VSTATUS=5 then 8 -- Vertrag
when POLICEN_ORDER.VSTATUS=6 then 8 -- Vertrag
when POLICEN_ORDER.VSTATUS=2 then 4 -- Fremdvertrag
else 0
end +
case when coalesce(POLICEN_ORDER.ABLAUF, current_date+1)<=current_date or
POLICEN_ORDER.VSTORNO=1 and coalesce(POLICEN_ORDER.STORNO,
current_date+1)<=current_date then 2 else 0 end);
-- and do some work with the data that will fail miserably in 2.5
update POLICEN_ORDER
set VSTATUS = 8
where (ID = 2);
commit;
-- this works in 2.0
select * from policen_order;
update POLICEN_ORDER
set VSTATUS = 2
where (ID = 2);
commit;
exit;
--------
Here is what happens in 2.0:
-------
....
update POLICEN_ORDER
set VSTATUS = 8
where (ID = 2);
commit;
-- this works in 2.0
select * from policen_order;
ID VSTATUS ABLAUF VSTORNO STORNO
============ ============ =========== ============ ===========
2 8 <null> <null> <null>
3 2 <null> <null> <null>
4 3 <null> <null> <null>
-----
and this is from 2.5
------
.....
update POLICEN_ORDER
set VSTATUS = 8
where (ID = 2);
Statement failed, SQLSTATE = 22008
value exceeds the range for valid dates
After line 52 in file bugtest.sql
commit;
-- this works in 2.1
select * from policen_order;
ID VSTATUS ABLAUF VSTORNO STORNO
============ ============ =========== ============ ===========
2 1 <null> <null> <null>
3 2 <null> <null> <null>
4 3 <null> <null> <null>
update POLICEN_ORDER
set VSTATUS = 2
where (ID = 2);
Statement failed, SQLSTATE = 22008
value exceeds the range for valid dates
After line 62 in file bugtest.sql
commit;
exit;
hth
fsg
|
Show » |
|
Statement failed, SQLSTATE = 08006
connection lost to database