Hello Helen.
I'm quite new in this IBO- and Delphiworld so please tell me if I'm
asking in a wrong forum.

We are using Delphi 6.0, IBO 4.7 and Firebird 1.5
We have some Product cards data which I show in a Delphi application.
1 card at a time from a TIB_query.

The user wants to be able to locate a specific No by entering the
number in the field and hit Enter.

I made an auto Searching to make the TIB_Edit open for entering the
numbers. But as you know this only find the specified card and they
have to make a new search on all to be able to scroll in all cards again.

The user want a feature as they have in some other Delphi applications
based on Paradox, where locate() is used.

Then I saw your comment about IBO in this mail:
<Particularly, it improves Locate() for those who believe they can't live
without it and it does some useful tricks with scrolling.>

This give me a hope for using an IBOcomponent for finding specific
cards and stay in the dataset, instead of copying the ideas from older
applications . Which component / parameter do I have to use?

My chalenge for using Card.locate() will be my Field is part of an unique
key and not all users are allowed to update this No.
In our older application I can see they use a TCombobox.

I hope I made myself a little more clear than in my last issue.

Thanks for many valuable inputs
Pia

--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 08:25 PM 2/09/2007, you wrote:
> >Some days ago, I downloaded the IBObjects components for testing.
> >
> >I have one problem with Interbase/Firebird databases and I want to
> >know if it is possible to solve it with IBObjects.
> >
> >I'm working with a remote connection to databases and I have a
table
> >with lots of records, when I use the Last()method to go to the last
> >record in table (I'm in a grid) I have to wait lots of time.
> >
> > How Can I speed up this situation?
>
> Don't use table components (or unlimited queries) for a client/server
> database. Use a query with a WHERE clause to limit the rows to only
> the ones that the user needs. And avoid (or minimise use of)
> workflows that have to step through large datasets in a loop.
>
> > The table has a primary key and I tried to create a second index
> >that is the same that primary key but in reverse order (with desc),
> >but the speed is the same.
>
> That won't hurt but it won't help, either. The client side doesn't
> use indexes in the ways that the VCL enables for local or file-served
> databases like Paradox and Access, where indexes are physical
objects
> that can be navigated. A descending index can be helpful for
> descending-order queries, greater-than searches and high-end
> aggregations but don't create them unless you actually have a use for
them.
>
> The slow part is in your application having to drag all of the
> records across the interface. With a Last() call, the dataset has to
> keep dragging records until the server's buffer is empty. There is
> no way to make this fast enough across a network to make sense
with
> whole-table sets on large tables. It belongs to desktop databases,
> where a "table set" is a local physical file. In client/server,
> every search involves round trips between the client application and
> databases on remote machines. You need to work zealously on
> designing datasets and operations that use client/server features
> efficiently. You could pick up the TechInfo sheet "Moving to
> Client/Server" from
http://www.ibobjects.com/TechInfo.html#ti_Moving_to_CS
>
> That said, a lot of work has been done in IBO over the years to
> refine implementation of those desktop-style navigation methods on
> bi-directional Fb/IB datasets. Particularly, it improves Locate()
> for those who believe they can't live without it and it does some
> useful tricks with scrolling. But designing interfaces that scroll
> to the end of huge datasets, or depend on a grid interface for
> accessing such datasets, is for desktop databases and
> spreadsheets. It is not a sensible thing to do in client/server if
> good performance is important.
>
> Helen
>