Subject [firebird-support]Corruption of PK Index FB1.5
Author Paul Hope
Hi
I have had a problem for some time with the PK index on one customer table.
The database backs up fine.
Restore using IBExpert interface -
On restore it falls over with 'String truncation etc'
On restore with verbose and commit each table it stops with . .
gbak: committing data for table BI_MOVEMENT_LOG2
gbak: 18119 records restored
IBE: The insert failed because a column definition includes validation
constraints.
validation error for column REC, value "*** null ***".
validation error for column REC, value "*** null ***".
validation error for column REC, value "*** null ***".
validation error for column ‰ø_^[Ã�öÁ…K, value "(null)".
IBE: Restore completed. Current time: 17:13:08. Elapsed time: 00:01:00

If I drop the PK and examine the data there are no nulls in the PK field.
If I reinstate the PK then it backs up and restores - for a while.

Table definition is . .
CREATE TABLE BI_MOVEMENT_LOG2 (
REC INTEGER NOT NULL,
TODAYX DATE,
DELIV_NUM INTEGER,
OLD_DATE DATE,
NEW_DATE DATE,
NGV NUMERIC(9,2),
CUST INTEGER,
OP INTEGER,
COMPANY CHAR(1)
);
ALTER TABLE BI_MOVEMENT_LOG2 ADD CONSTRAINT PK_BI_MOVEMENT_LOG2 PRIMARY
KEY (REC);
CREATE INDEX BI_MOVEMENT_LOG2_IDX1 ON BI_MOVEMENT_LOG2 (TODAYX);
CREATE INDEX BI_MOVEMENT_LOG2_IDX2 ON BI_MOVEMENT_LOG2 (DELIV_NUM);

/* Trigger: BI_MOVEMENT_LOG2_BI */
CREATE OR ALTER TRIGGER BI_MOVEMENT_LOG2_BI FOR BI_MOVEMENT_LOG2
ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
IF (NEW.REC IS NULL) THEN
NEW.REC = GEN_ID(GEN_PURPOSE,1);
END

All the data is within the capacity of the fields.
The table is only updated from a stored procedure here . .

select first 1 rec,old_date from bi_movement_log2 where todayx=:todayx and
deliv_num=:deliv_num and company=:company
into :r,:ood;
if(r is null and(oddate<>nbdate)) then
insert into
bi_movement_log2(TODAYX,DELIV_NUM,OLD_DATE,NEW_DATE,NGV,CUST,OP,COMPANY)
values
(:todayx,:deliv_num,:oddate,:nddate,:ngv,:cust,:op,:company);
else begin
if(ood=nddate) then
delete from bi_movement_log2 where rec=:r;
else
update bi_movement_log2 set new_date=:nddate,op=:op where rec=:r;
end

The logic doesnt make total sense but I cant see it doing any harm.

The customer reports nothing in the event logs to suggest a disk
problem, not sure if this is exhaustive.
The customer promises that there are no backups, copying or any windows
based functions accessing the database file.
Operating system Windows Server 2003.

Any ideas - please!

Regards
Paul