--- In IBObjects@yahoogroups.com, "Jason Wharton" <jwharton@i...>
wrote:

> Steve said:
>
> Since the MajorID is the primary key for the xMajor table, it
> uniquely identifies a record (see the where clause). The GroupID

is

> the primary key for the xGroup table. I've changed the query to
>
> select ma.MajorID, ma.MajorName, gr.GroupID, gr.GroupName
> from xMajor ma
> join xGroup gr on gr.GroupID = ma.GroupID
> where ma.MajorID = :MajorID
>
> which is almost the same as it was. I've changed the KeyLinks to
>
> xMajor.MajorID
> xGroup.GroupID
>
> Again, these are the primary keys for both tables involved in the
> query although the only one needed to uniquely identify a record is
> the xMajor.MajorID.
>
> I'm still getting the same error.
>
>
> Jason replies:
> It may be sufficient to uniquely identify a record in the ones

returned to

> the dataset but you need to make it sufficient to uniquely

identify a record

> in the database. If you take a careful look at the SQL being

generated in

> the trace monitor it would probably help give you greater insight

here.

>
> There might also be something I can improve on the inside.

Contact me

> privately and request the beta of my next sub-release and give it

a whirl.

> It may impact this for good.
>

I finally resolved this. It was apparently a KeyLinks issue. When
I changed the KeyLinks property for the query being used for the
delete, the error started occuring in a second query used for
display. I didn't realize the error had moved from one query to
another so I assumed that the KeyLinks was not the cause. When I
also fixed the KeyLinks property for the query used for display, the
problem was resolved. I'm still not sure what the KeyLinks property
is or why it's needed but I think the fog is beginning to lift.

Thanks to everyone for your help,
Steve