At 07:23 AM 19/06/2003 +1000, you wrote:

> > Hi all,
> >
> > The keylinks functionality in the TIB_Query component is not very well
> > explained
> > It seems to me that this functionality is only of interest for
> > client-applications
> > In my case (a web (server)-application)

A webserver application is a client application. Even gfix is a client
application.

>I always need to get in the
>complete
> > resultset
> > Also I do not connect the TIB_Query to any datasource / grid or other
> > component
> > for presentation of data.
> > Therefore I would think that I do not need at all the keylinks
> > functionality, is that correct ?

Keylinks are read to determine which unique values to hold in the Keyfields
buffer. This buffer is what IBO uses to determine its "windows" for
manipulating sections of datasets in and out of the row buffers. Its other
main uses are to extract the key values for locates, searches and DML
operations (how else will the app know which row to
update/delete/locate?); to identify rows that are invalidated by edits and
deletes so that the dataset knows what to put back after a refresh; and the
IBO bookmarking scheme uses the Keyfields buffer, too.

What is being done with the data? It would help a lot to know. Are you
using a TIB_Query or a TIB_Cursor? If a TIB_Query, why do you need a
scrolling dataset?

> >
> > Could someone tell me how the keylinks functionality can be disabled
> > completely ?
> > That is: which properties should be set to what ?

This is really like asking how to stop IBO datasets from working.

> >
> > In the help file I read
> > - with "FetchWholeRows := False" the buffer is split (keys and remaining
> > whole record buffer)
> > and three cursors are used internally by TIB_Query
> > I got the impression that in this situation the keylinks are used
> > - with "FetchWholeRows := True" one cursor is used internally by TIB_Query
> > and the query is processed like the Delphi TQuery without splitting the
> > buffer
> > From this I got the impression that with "FetchWholeRows := True" the
> > keylinks
> > functionality is disabled

When FWR is false, IBO will pull over first the Keyfields for the whole set
(which it determines via Keylinks) and then it will get the whole rows into
the row buffer on demand. When it's true, IBO fetches the whole rows first
and builds up the keyfields as it goes. On a server-based client, there
shouldn't be any noticeable difference, since there is no wire traffic. On
a remote client, it can make a difference to how fast the first data
packets become usable in the buffer.

> >
> > However, after setting FetchWholeRows := True I still get keylinks errors
>in
> > my queries

If there is no updating or locating going on, and you have the key columns
in your output set, you can simply remove any keylinks entries you have and
set KeyLinksAutoDefine to True. After that, examine the Keylinks to see
what IBO worked out. Without joins and with a single-column primary key,
that is actually present in the output set, the autodefine will probably be
right; with complex keys, maybe; with joined sets, it will be
wrong. Whether that's important depends on what you are using the data for.

> >
> > (By the way: i'm still using version 3.4c for this application)

Gosh, that is OLD (like 4 years!!). If you like, ask me for a link to the
latest v.3 version. Jason backported some of the v.4 HDR stuff to it a
couple of years ago. But that doesn't imply that I think 3.7 will solve
your problem! It's going to be hard to find a solution to the problem
unless you tell us what the problem is...

Helen