Subject | Re: [ib-support] Re: census cases of databases corruption |
---|---|
Author | Paul Schmidt |
Post date | 2003-05-13T12:40:38Z |
On May 12, 2003 12:12 pm, mk_delphi wrote:
the DML changes have been committed at best. The reaction would be the
same as any other pre-existing record. If your smart, then you always
provide a default value, so it can apply the default value to those rows
when it adds the column to the existing record.
DB Recovery is a different problem, and that is where you change a
NULLable column to NOT NULL by changing a system flag, so there are
existing records out there with NULL values. I don't know the solution
here, various ones have been discussed, not sure whether FB1.5's GBAK has
been fixed for this or not....
Paul S
> Hi Paul,First, an already running transaction would not see your column, until
>
> > > -Changing metadata while database in use
> >
> >... is a common enough procedure that if this were a problem it
> > would be very well known.
>
> What appen if I add a NOT NULL colum to a table when there are
> other clients updating the table? How their transaction can handle
> this
> situation? Should be the DB not recoverable after a backup?
>
the DML changes have been committed at best. The reaction would be the
same as any other pre-existing record. If your smart, then you always
provide a default value, so it can apply the default value to those rows
when it adds the column to the existing record.
DB Recovery is a different problem, and that is where you change a
NULLable column to NOT NULL by changing a system flag, so there are
existing records out there with NULL values. I don't know the solution
here, various ones have been discussed, not sure whether FB1.5's GBAK has
been fixed for this or not....
Paul S