--- In ib-support@y..., "rodbracher" <rod@m...> wrote:

> how do I drop a rdb$primary67 index ?

Rob, it is automatically created index which support Primary Key
(PK) constraint on one of your tables. You can't drop this index but
you can drop PK itself and index will be automatically dropped. If
there are Foreign Keys from another tables to this PK, you should drop
them previously.
To find this table use
Select RDB$RELATION_NAME From RDB$INDICES
Where RDB$INDEX_NAME='RDB$PRIMARY67'

After it I recommend to find duplicates using

Select <columns on which PK was specified>, Count(*)
From This_Table
Group By <columns on which PK was specified>
Having Count(*)>1

if there are really duplicates (reason - index was broken, I
encountered such a problem two times for 7 years of experience with
IB/FB) you can make a decision what to do with them (another situation
I'll describe later)
a) repair - SP like (assuming PK was on 1 integer column ID and filled
with generator, if not, you can adapt the idea):

CREATE PROCEDURE REPAIR_PK(DUP_VALUE INTEGER)
AS
DECLARE VARIABLE ID INTEGER;
DECLARE VARIABLE FIRST_STEP INTEGER;
DECLARE VARIABLE NEW_ID INTEGER;
BEGIN
FIRST_STEP=0;
FOR SELECT ID
FROM THIS_TABLE
WHERE ID=:DUP_VALUE
INTO :ID
AS CURSOR TMPCURSOR
DO
IF (FIRST_STEP=0) THEN
FIRST_STEP=1; /*LET ONE OF THEM USE OLD PK VALUE*/
ELSE
BEGIN
NEW_ID=GEN_ID(GEN_FOR_THIS_TABLE,1);
UPDATE THIS_TABLE SET ID=:NEW_ID
WHERE CURRENT OF TMPCURSOR;
END
END

b) delete duplicates - similar procedure which delete all of them
except one instead of update.

If you could'nt find duplicates - this mean you have another type of
corruption: null-filled record(s). It usually happens after crash of
the server when it do garbage collection. Try to repair database using
gfix -v -f, gfix -m and after this

DELETE FROM THIS_TABLE WHERE ID IS NULL
DELETE FROM THIS_TABLE WHERE ID=0

and try to re-create dropped previously PK.

HTH, Alexander V.Nevsky.