|Subject||Re: [IBO] Locate problem with beta 4.7 beta 11|
> > > What was fixed in IBO was the underlyingthat
> > > 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
> it makes sense to shift some of the work of locating a record to theserver.
Yes, I know. Didn't realize it in this particular situation though ;)
> This is more especially true when you are employing the horizontal datasetBetter do so then :-)
> 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.
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Database development questions? Check the forum!