Hi All once more. I wrote
> I have three questions.
> 1. Why it happened and what I must do to prevent it in future.
I don't know it and it is intresting. Damaded table and contents of
is 3 damaded records are (found accordingly message on restore try by
nulls in not null columns after gfix -mend)
SHOW TABLE sch_prices Values
KODTOV INTEGER Not Null 0
SCTIP INTEGER Not Null 0
SCSTORE INTEGER Not Null 0
SCNOMER INTEGER Not Null 0
TIPREC CHAR(1) CHARACTER SET WIN1251 Not Null
DATEORD DATE Not Null 17-NOV-1858 00:00:00
DATEREG DATE Nullable Default "NOW" <null>
TABREG CHAR(6) CHARACTER SET WIN1251 Nullable Default USER <null>
NUMREG CHAR(6) CHARACTER SET WIN1251 Not Null
ZALIV CHAR(1) CHARACTER SET WIN1251 Nullable <null>
PRUDAL CHAR(1) CHARACTER SET WIN1251 Nullable <null>
CONSTRAINT SCPR_PK:
Primary key (KODTOV, TIPREC)
CONSTRAINT SCPR_FKSC:
Foreign key (SCTIP, SCSTORE, SCNOMER) References SC_POST (TIP,
STORE, NOMER)
CONSTRAINT SCPR_FKNOM:
Foreign key (KODTOV) References NOMENKL (CODE)
Normally, due to app logic, reference constraints and before insert
trigger on this table, it can't contain any 0's and nulls.
Curious is null represented by 17-NOV-1858 00:00:00 in one of date
columns and <null> in others... And I always thought null is
31-DEC-1899, but restore recognized it as null.
> 2. How can I repair .gdb to state when I can do backup/restore.
Hint for others in the same situation: having error message from
gbak when restoring after gfix -mend and backup, we can localize
damaged records and delete them. Of course I should realize it at
once
but in such situation people feel some light panic :)
> 3. How can I determine what data is lost after 2.
Fortunately, it's not fundamental question in this case, I can do
it
analyzing other tables, it requires only some work. But what should
do
other man (or I next time) whose fundamental table is damaged?
Mournful is that we Firebird users can't hope on help in Borland's
newsgroups, (I suspect on mers too and kept myself from questioning
there too) and this one is not very populousness yet...