At 01:17 PM 14/10/2003 +0000, you wrote:

>Helen,
>
> > >Invalid custom DML column reference: RDB$DB_KEY.
> >
> > It's probably a relic in one or more of your ***SQL properties from
> > the previous bad Keylinks setting. Just inspect them and take them
> > out.
>
>Bull's eye! Thanks! :)
>
> > Automatic keylinks only works if you have a primary key on the
>table. > It doesn't work with joined sets or views, either.
>
>This is worth to remember. I also noticed that automatically generated
>update/insert/delete SQL statements tend to use RDB$DB_KEY on joined
>views, rather then actual PK. So I guess this is related then?

Yes - it's related. IBO (AFAIK) is the only component set that can give
you a "live" dataset on non-updatable queries. IBO makes a lot of use of
the DB_KEY when trying to identify a row uniquely - kind of "when all else
fails" it will resort to that feature. But with joined sets (generally
speaking) you need to work out the unique column-group for keylinks in
order to really "hit the nail on the head" for updates. Views are simpler,
but of course there are no keys for IBO to use to work things out - it's
really much the same situation as your unkeyed tables.

>I never really thought about this, because IBX for example didn't
>treat views any differently than tables. At least from the outside view.

What's inside IBX isn't much different from what you see from the outside
view. The two component sets aren't really comparable except to the extent
that they both happen to provide an object interface to the API.

Helen