>
> -----Original Message-----
> From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com] On

Behalf Of Helen Borrie

> Sent: Saturday, July 29, 2006 12:03 PM
> To: IBObjects@yahoogroups.com
> Subject: RE: [IBO] Quoted fields seem to be broken in TIBODataset when

they're involved in indexing

>
>
> 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.)

What??? Must be late in the day there <g>.

"procedure TIBODataset.FindNearest( const KeyValues: array of const );"

An "array of const" is a Variant Open Array, which basically means the
members of the array are untyped at compile time. It's equivalent to
array of TVarRec. The members are passed by value, which is
what I expect you meant.

ID is an integer variable which has (IIRC) a value of 5 at the time of
the call , e.g., FindNearest([5,nil,nil]);

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

Tried it, same issues.

>
> > >
> > > 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?
>

It gets the primary key as the Order By fields , of course; try it and
see what SQL you get if you're not using bizarre field names.

> >
> > >
> > > 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...)
>

IBO *does* know the structure. This is evident in the fact that tables
which don't have any primary key columns which require quoting for
Firebird work exactly as one would expect. It's borne out by looking
at the code. What's happening is exactly as I said: the fact that
fields may need quoting because they contain blanks or are keywords
or start with numbers or other such things is not handled in IBODataset,
or for that matter in other places in IBO.

> >
> >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

It knows what the KeyFields are, I've stepped through the code. It just
can't find them because it's comparing "Acc ID" to Acc ID (or more
precisely, ARINV."Acc ID" to Acc ID).

I know I'm not in Kansas (or using Paradox) any more, I've been writing
code for money for around 38 years. I've used many databases on many
machines with many compilers. I can get away with keeping the
TIBOTables for a while because most of the tables have a couple of
hundred rows. I'm just trying to mimimize the elapsed time until I
can get the app working with Firebird in the same manner as it did
with the BDE so we can move on to the improvements phase.

This is a bug, no question. It's obviously not a bug that has ever
disturbed anyone else, because for many good reasons, no one uses such
field names. Whether IBO will (or even should) fix it is not my call. I
can see some of the places in the code were fairly simple changes will
fix these issues, but I don't know what ripple effects such changes may
have. Quite frankly, I'd be inclined to stick it on the "not supported"
list forthwith if positions were reversed.


Michael D. Spence
Mockingbird Data Systems, Inc.

P.S.

Love your book.


[Non-text portions of this message have been removed]