Martijn Tonies wrote:

> Jason wrote:
> > What was fixed in IBO was the underlying
> > problem of IBO not putting the locate query
> > on the server together correctly. When doing
> > that I have to take into consideration of the
> > underlying column name because that is the
> > data I need to look through. I believe it
> > will allow the locate on either the underlying
> > SQLName or the actual AliasName of the column
> > as far as identifying what column is being
> > searched against.
>
> Right, I thought "locate" was a client side thing only.

IBO uses the server as much as possible (sensible) and there are times that
it makes sense to shift some of the work of locating a record to the server.
This is more especially true when you are employing the horizontal dataset
refinement capabilities of IBO. You can be out in the middle of a huge
dataset and scolling backwards and forwards can result in records getting
fetched and calling Locate() can be nothing more than sliding to a new
window of records.

> > Obviously, if there is ambiguity that the alias is required to
> distinguish,
> > then it is the responsibility of the programmer to be sure
> they do the
> > locate based on the alias and not the potentially ambiguous SQLName.
>
> Have you considered the case where there's no column name?
>
> eg:
>
> select 'test', *
> from ...
>
> etc?
>
> Imagine "test" coming from some formula or whatever...

There is a default name of column given columns and I leave it up to the
programmer to inquire as to what it is if they plan on using things like
FieldByName() or Locate().

Yikes! I need to get some sleep, the sun is coming up in a few minutes.

Regards,
Jason