Subject | Re: [IBO] Lookup field causing this --> internal gds consistency check(partner index description not found (175)) |
---|---|
Author | Helen Borrie |
Post date | 2002-12-13T15:16:22Z |
At 04:37 PM 13-12-02 +0200, you wrote:
database. Because of where it showed up, I'd suspect that you have either
a corrupted index on the primary key column of that lookup table, or a
corrupted foreign key column index on the main table. I hope you have a
recent backup.
As to how it happened, there are a few possibilities, none related to
IBO. A common one for the unintiated is running the server with Forced
Writes disabled, especially on a Windows machine. Another common one is
when newbies attempt to perform SQL operations directly on the system
tables - they invariably break things. Another one is when the hard disk
becomes physically damaged, e.g. by power surges or 101 other things that
can eat disks. Corruption can also occur if you use a filesystem backup or
copy utility while the database is running.
Fixing the problem is just about as hard as finding it. If it's an index
corruption, you might be able to recover by dropping and recreating the
offending index(es). If there are keys involved, that may be quite a
complicated task.
There is a paper in the documentation area at IB Phoenix on the topic of
repairing a corrupted database, if you can't get it back up and running by
operating on metadata.
For more on database corruption, search the archives of the ib-support list.
Helen
>I have a lookup field 1 that works fine if used.Alas, what it means is that you have some corruption in your
>But when I use the second lookup field , it generates the following error :
>internal gds consistency check(partner index description not found (175)) ,
>
>
>
>What does this mean ?
>
>
>
>I am forced to RE-START firebird after this since it says,
>
>can not continue after bug check.
database. Because of where it showed up, I'd suspect that you have either
a corrupted index on the primary key column of that lookup table, or a
corrupted foreign key column index on the main table. I hope you have a
recent backup.
As to how it happened, there are a few possibilities, none related to
IBO. A common one for the unintiated is running the server with Forced
Writes disabled, especially on a Windows machine. Another common one is
when newbies attempt to perform SQL operations directly on the system
tables - they invariably break things. Another one is when the hard disk
becomes physically damaged, e.g. by power surges or 101 other things that
can eat disks. Corruption can also occur if you use a filesystem backup or
copy utility while the database is running.
Fixing the problem is just about as hard as finding it. If it's an index
corruption, you might be able to recover by dropping and recreating the
offending index(es). If there are keys involved, that may be quite a
complicated task.
There is a paper in the documentation area at IB Phoenix on the topic of
repairing a corrupted database, if you can't get it back up and running by
operating on metadata.
For more on database corruption, search the archives of the ib-support list.
Helen