Subject | RDB$INDEX_16 - mainly support question. |
---|---|
Author | Alexander V.Nevsky |
Post date | 2001-11-22T18:43:52Z |
Hi, All.
Introduction, maybe useful for FB team. Sequence of events.
Having 3 simultaneos connections to LI-T1.0.0.368 (application,
makes nothing, started and forgotten, opened TIBDatabase in Delphi IDE
and WISQL where I worked) I added not null column to short table with
data, filled it by some single updates and tried to create FK from
this column to another table. First time I forgot to fill 1 line, got
exception and corrected mistake. Second time I forgot I have index on
parent table that is the same as PK, got exception, dropped this index
and tried to establish reference third time. Now I got exception -803
attempt to store duplicate value (visible to active transactions) in
unique index "RDB$INDEX_16"
and since that time I can't do any changes to this table - add column,
drop column etc. The same error every time. I made copy of this table
to temporary and can do all what I want with it, including creation of
those FK. It was'nt first time when this build showed strange behavior
when metadata were changed having more than 1 connection. I have
LI-T6.2.555 installed on another server and some days earlier copy of
this database on it. I made the same on this database - made the same
connections and run saved WISQL session that corrupted RDB$FORMATS or
RDB$INDEX_16 on 386 as script. No error - it seems you eleminated it's
reason between 386 and 555, congratulations.
Now question. It's a rather big database and I made really many
metadata changes and data filling on it since last copy. Attempts to
backup/restore or drop and re-create table (many dependencies and
FKs) or repeat my changes on another copy requires about half a day if
b/r can repair or much more if it can't. Is'nt there any (hack)
possibility to quick repair RDB$FORMATS or RDB$INDEX_16 by hands (any
delete/insert/update in some system table)? Just copy it's records in
RDB$FORMATS from temporary twin, for example? If not, no big problem,
there is'nt live production database, just my copy for developing and
my own time.
Thank you.
Introduction, maybe useful for FB team. Sequence of events.
Having 3 simultaneos connections to LI-T1.0.0.368 (application,
makes nothing, started and forgotten, opened TIBDatabase in Delphi IDE
and WISQL where I worked) I added not null column to short table with
data, filled it by some single updates and tried to create FK from
this column to another table. First time I forgot to fill 1 line, got
exception and corrected mistake. Second time I forgot I have index on
parent table that is the same as PK, got exception, dropped this index
and tried to establish reference third time. Now I got exception -803
attempt to store duplicate value (visible to active transactions) in
unique index "RDB$INDEX_16"
and since that time I can't do any changes to this table - add column,
drop column etc. The same error every time. I made copy of this table
to temporary and can do all what I want with it, including creation of
those FK. It was'nt first time when this build showed strange behavior
when metadata were changed having more than 1 connection. I have
LI-T6.2.555 installed on another server and some days earlier copy of
this database on it. I made the same on this database - made the same
connections and run saved WISQL session that corrupted RDB$FORMATS or
RDB$INDEX_16 on 386 as script. No error - it seems you eleminated it's
reason between 386 and 555, congratulations.
Now question. It's a rather big database and I made really many
metadata changes and data filling on it since last copy. Attempts to
backup/restore or drop and re-create table (many dependencies and
FKs) or repeat my changes on another copy requires about half a day if
b/r can repair or much more if it can't. Is'nt there any (hack)
possibility to quick repair RDB$FORMATS or RDB$INDEX_16 by hands (any
delete/insert/update in some system table)? Just copy it's records in
RDB$FORMATS from temporary twin, for example? If not, no big problem,
there is'nt live production database, just my copy for developing and
my own time.
Thank you.