At 03:57 PM 2/07/2003 +0000, you wrote:

>No way ?
>It could check RDB$VIEW_RELATIONS.
>
>By the way, it would have to do it recursively, because
>the resulting *relation*-names are not necessarily tables but might
>be views themselves.

Yes, I thought about that after I posted on it.

> > I can't see why this should be a problem - a warning isn't an
>error - and
>The problem is that this warning is false and therefore very
>misleading.

Actually, the warning is correct. All the warnings do is say what the
metadata-extract object expected - they don't necessarily indicate anything
wrong, provided the beholder understands the metadata.

>At least, this warning does not read "I have no real idea about how
>big your dbkey should be and I have no way to caclulate it but I
>warn you that I would prefer 8 over your 152"
>Indstead it reads "DBKey_Length should be 8 but is 152 instead".
>I understand this warning as "There is something wrong in your
>database. Your db-key length is 19 times too big. That might work
>for you at the moment but you should look after it soon."

I think it actually prompted you to investigate something you didn't
understand. AFAIU, that's the purpose of warnings.

>Of course, NOW that I know how to judge it, it is no problem any
>longer.
>I posted that message just as a proposal for improvements:
>To save other people the mess I had.

The view issue looks like an area where enhancements could be made to
extend the component's features for use as an analysis tool, albeit without
in any way enhancing the extraction of metadata (the component's current
purpose).

But it's highly debatable whether a component designed to extract metadata
has a role to teach you things about the engine internals. And that's what
the RDB$DB_KEY is. It isn't surfaced in the language. It's a "trick" that
a group of knowledgeable IBO developers (Claudio, followed by Jason,
followed by Geoff) have surfaced for use in certain contexts - for example,
to raise a flag when you are investigating a problem with a view....?

>Additionally there is a slight chance that Jason has overlooked this
>(rare?) constellation not only in the metadata-extract part of
>ib_sql but in the ibobjects-access components as well (I don't know
>much about the inner workings of ib-objects but I guess that he is
>making heavy use of dbkeys

No, the data access components don't make heavy use of
dbkeys. Principally, dbkeys are part of the engine's internal housekeeping
mechanism to manage the cardinality of sets. Under a particular set of
conditions - where KeyLinks can't be determined from either the query
specification or the metadata - IBO datasets pick up on this mechanism to
impose a unique identifier on an output set. On the IBO side, they are not
even the hex number groups returned in the XSQLDA - they are munged into a
string. They cannot be used to search tables on the database. You should
never treat them as a bona fide SQL column for DML purposes, because they
have no validity beyond the moment your transaction started.

>; so for example allocating a 8-byte
>buffer because he expects the dbkey to be of such size could be
>fatal if the key is 32 bytes size instead.)

Erm, I don't think you need to worry about that. IBO is not new
software. We've been using views and selectable stored procedures with IBO
for years.

cheers,
Helen