| Subject | RE: [IBO] Dynamic Query |
|---|---|
| Author | Helen Borrie |
| Post date | 2002-09-06T02:44Z |
At 11:09 AM 06-09-02 +1000, you wrote:
KeyLinks for a great number of its tricks in the buffers, including its
very flexible Bookmark capabilities, RefreshKeys and for controlling the
flow of data from sets that are waiting on the server for Fetch calls from
the client (and other stuff as well).
HOWEVER... and this is the trap you have fallen into...Jason ALSO uses
KeyLinks in a different format for the Lookup-to-Keysource linking. It is
possible to make KeyLinks do both jobs simultaneously in a lookup dataset
because it is always the primary (or unique) key of the lookup's set that
links to the polling key in the Keysource dataset. When a dataset has a
Keysource, IBO knows that KeyLinks is doing both jobs.
In case you hadn't noticed yet, the dataset classes have a Boolean property
KeyLinksAutoDefine. In "simple" select statements, where you are just
pulling a set from a single table and it includes the primary key, you can
set this property to True and IBO will define the KeyLinks for
you. However, on a joined set, even if you set KeyLinksAutoDefine true,
you won't get the proper columns in the definition...I *think* possibly IBO
will use the [RDB$]DB_KEY under these conditions.
Since you and I are both in serious overload at present, I hope I don't
regret mentioning DB_KEY - it's an "inside trick" that uses an undocumented
feature of InterBase (but a documented feature of Firebird, if you have
access to the Firebird manuals) - you can read up about it by searching the
IBO online FAQ or looking up the articles on Claudio Valderrama's site at
www.cvalde.com ...or by buying the IBPhoenix CD. :-)
Helen
>Helen,You got it. You got it. You got it.
>
>The terminology seems to be the thing I have to get use to also.
>
>With regards to my KeyLinks issue, are you saying that the identifiers in
>KeyLinks must represent a unique combination of fields in the output set.
> >From memory I read that KeyLinks can include fields not in the output set.I think it was once true but may have changed. Try it out and see.
>Am I correct with this ?
>If the above is correct then does this mean KeyLinks is predominantly usedIts duality actually quite distinctly explained in the GSG. Yes, IBO uses
>for something internal to IBO as opposed to defining a relationship between
>the input and output sets.
KeyLinks for a great number of its tricks in the buffers, including its
very flexible Bookmark capabilities, RefreshKeys and for controlling the
flow of data from sets that are waiting on the server for Fetch calls from
the client (and other stuff as well).
HOWEVER... and this is the trap you have fallen into...Jason ALSO uses
KeyLinks in a different format for the Lookup-to-Keysource linking. It is
possible to make KeyLinks do both jobs simultaneously in a lookup dataset
because it is always the primary (or unique) key of the lookup's set that
links to the polling key in the Keysource dataset. When a dataset has a
Keysource, IBO knows that KeyLinks is doing both jobs.
In case you hadn't noticed yet, the dataset classes have a Boolean property
KeyLinksAutoDefine. In "simple" select statements, where you are just
pulling a set from a single table and it includes the primary key, you can
set this property to True and IBO will define the KeyLinks for
you. However, on a joined set, even if you set KeyLinksAutoDefine true,
you won't get the proper columns in the definition...I *think* possibly IBO
will use the [RDB$]DB_KEY under these conditions.
Since you and I are both in serious overload at present, I hope I don't
regret mentioning DB_KEY - it's an "inside trick" that uses an undocumented
feature of InterBase (but a documented feature of Firebird, if you have
access to the Firebird manuals) - you can read up about it by searching the
IBO online FAQ or looking up the articles on Claudio Valderrama's site at
www.cvalde.com ...or by buying the IBPhoenix CD. :-)
Helen