At 12:39 AM 30/07/2006, you wrote:

> >
> > First things first, though. please provide the following:
> >
> > 1. The EXACT FindNearest expression that fails. (Your example isn't
> > valid and it's inadequate to guess what is being offered up).
>
>That isn't an example, it's the actual code. It was valid for
>the BDE.

I don't believe you. The argument for FindNearest is an array of
constant values (which may be NULL or nil, but ID is not a constant value.)

> > 2. The KeyLinks EXACTLY as you have them defined.
>
>Haven't defined any.

Do so.

> >
> > 3. The IndexFieldNames string EXACTLY as you have it defined.
>
>None, because I'm using the primary key.

Beg pardon, but what do you think that gets you?

>
> >
> > 4. Also, remind us what EXACT version of IBO you are using (you can
> > get this by looking at the Version property of your IBODatabase
> > object in the Object Inspector).
> >
>
>4.6.B
>
>
>There's an internal inconsitency in the way IBODataset treats field
>names. When looking up indexed fields, it's doing FindField() on the
>TIBOTable. The field names are stored as they were with the BDE, e.g.,
>'Acc ID', 'Invoice #'. However, the string it's using for the search is
>the fully qualified field name, e.g. 'ARINV."Acc ID"', 'ARINV."Invoice
>#"', so of course FindField always fails.

The "internal inconsistency" is arising because you have not provided
KeyLinks. IBO does not *know* the structure of your indexes. It is
guessing and is getting defeated by what it is parsing out of the
column names. Turn off KeyLinksAutoDefine and define the KeyLinks
explicitly. (I'm not certain that IBO will be friendly towards that
"#" symbol, though...you can but try...)

>
>I've changed the code to deal with this and the FindNearest works, but
>there are multiple places which do this FindField, so I still get the
>"Not Indexed..." error. This is caused by the same sort of apples and
>oranges comparison at a different place, but I had to leave yesterday
>before I could patch that up and try it out.
>
>I can send you the code directly if you want to see what I mean
>(I'm reluctant to post much about the source code since it's a
>licensed product).

You don't need to. Just accept that you're not front-ending Paradox
here. Table components were never intended for use with database
servers and there are just simply some things that won't work like
they did in Paradox. Accessing indexes from the client is
one. Doing Find.. searches is another. IBO implements a mechanism
called horizontal dataset refinement which, if used on well-defined
datasets, makes life a bit less dogged when working with table
components and also makes it possible to emulate the Find... methods.

HDR is malfunctioning with what you have there. It *needs* the
properly-defined KeyFields to work; and KeyFields won't be properly
defined until you explicitly and correctly define your KeyLinks. If
you get *that* right, you won't need IndexFieldNames but I raised it
really wondering whether you had a conflict between them.

Helen