Helen,

> To get rid of the DB_KEY, simply set the KeyLinks to the primary
> key column(s) of the table. It will have to be more than just
> ID, apparently, otherwise you wouldn't use SELECT FIRST.

This made me check my settings. I was originally using
KeyLinksAutoDefine=True for my query. After I set this property to
false and specified the KeyLinks manually, the statement was parsed
correctly at runtime.

I'm still getting an error at design time, though. However, it doesn't
occur during preparation, but rather during opening/closing of the
dataset.

This is the message:

---------------------------
Invalid custom DML column reference: RDB$DB_KEY.
---------------------------

Things seem to work at runtime, which is what really matters to me.

But I'm still intrigued... Does this mean that automatic key links
generation is broken somehow? Any special reason for this? And what
about this DML message I'm getting at design time?

Nontheless, thanks for the insights about bracketing. I'll take this
into account.

The real reason for those (obviously redundant) brackets is my WHERE
clause generation routine, which can handle any number of conditions.
For simplicity's sake I decided to have it bracket every single
condition. I guess I'll be revising this soon. :)

Kind regards,
Aleksander Oven