--- In ib-support@y..., "Ivan Prenosil" <prenosil@m...> wrote:

> > Simply example - null in _not null_ column,

we

> > can make this mistake ourselves changing metadata, sometimes such

a

> > records appears when server crashed with unfinished garbage

collection

> > process. Such a corruption is not checked on backup, it's too
> > expensive.
>
> Checking referential (and unique) constraints would be expensive,
> but checking Not Null should be cheap.

Yes, you are right, Ivan, I choiced wrong example to speek about
absence of validation of data on backup. BTW, I'm once more surprised
with astonishing synchronism of discussions of the same subjects in
different newsgroups. Just now we have long and interesting discussion
with participation of Dmitry Yemanov about improving gbak
functionality to eleminate concept "unrestorable gbk" at main Russuan
FB forum. We are close to consensus and when it will be reached I'll
post result here. Most probably it will be plan for gradual
improvement, not one-time action and it is unlikely this efforts be
made for FB 1.5 which is aimed to fix migration of code base to C++.
Checking validity of simply constraints such as NOT NULL and CHECK on
backup is'nt a problem, but it is near to idleness by itself, stopping
of backup process is'nt a solution, there should be logging mechanism
and this log should be used on restore of gbk which contains invalid
data.

Best regards, Alexander V.Nevsky.