At 05:54 PM 15-10-02 +0930, you wrote:

>Helen Borrie wrote:
> >
> > At 05:07 PM 15-10-02 +0930, you wrote:
> > >The KeyLinks entry automatically provided is:
> > >
> > > "Animal Vendor".RDB$DB_KEY
> > >
> > >How to make the KeyLinksAutoDefine provide the correct key?
> > >
> > >The correct primary key is:
> > >
> > > "Animal Vendor"."Vendor ID"
> > >
> > >which is also considered invalid.
> >
> > Actually define a PRIMARY KEY constraint for the
> > table. KeyLinksAutoDefine needs a primary key upon which to define
> > KeyLinks (surprise, surprise). Without a PK, DB_KEY is all it has to work
> > with (and it's quite valid, but within the context of the transaction
> only.)
> >
> > ALTER TABLE "Animal Vendor"
> > ADD CONSTRAINT PKWHATEVER PRIMARY KEY ("Vendor ID");
> >
> > Do this with exclusive access and remember to COMMIT it.
> >
> > If you want to continue life without primary key constraints, then be
> > prepared to manually define all of your KeyLinks.
> >
> > btw, if you don't want to get DB_KEY returned in your output sets, don't do
> > SELECT * queries.
> >
>
>The table already has a primary key: "Animal Vendor ID".
>The SELECT statement specifies explicitly:
> "Animal Vendor ID"
> Vendor.
>
>So what else could cause the problem?

If IBO is bringing back RDB$DB_KEY as the autodefined Keylinks for

select "Animal Vendor ID", Vendor
from "Animal Vendor"

then you can bet your house that you don't have a primary key defined for
"Animal Vendor". If you migrated this database from an ISAM database and
imported its keys, you did NOT get a primary key out of it. A unique index
doth not a primary key make. In the creation of a PRIMARY KEY constraint,
the database will create the unique index to enforce the constraint, but
the reverse is not true.

Helen