Hello:
This is my situation. Over the years I have written many DB
applications first using DOS/BTrieve then Windows/Delphi/Paradox.
Although the applications run fine, because of the BDE problems and
some instability with Paradox I want to convert the applications to
something else. When I discovered IBO it seemed like the answer.
Your documentation states that the applications can be easily
converted to IBO and that IBO emulates BDE 100%. Although this is
true, the applications were easy enough to convert, they run totally
differently. Very slow. My point is that you can not do a direct
conversion. They do work but not in an acceptable manner. That
being said I am more than willing to do some homework and make the
necessary conversions but given that I have never worked with
Interbase, IBO, or Client/Server before I am somewhat at a loss.
The application I am trying to convert is very simple. There are 2
grids on the screen. One displaying records in the main file that
has 3 million + records. The other display records in a much
smaller file that is a subset of the main file. In the BDE version
of the application the user searches the small file and finds the
record of interest. Let's say a particular person with a $ amount
over $2000. In the afterscroll method of the small file I do a
locate into the large file. This way when the user searches the
small file and finds a record of interest they also see any matching
records in the large file. In the small file they may only be
looking for $ over $2000 but once found they want to see all $
amount belonging to that person. I realize that I could do a query
that selects only records belonging to that person once found in the
smaller file but the client does not want to limit his view into the
large file, they still want to see all people/ all $ amounts, they
want to see all records but simply be positioned to the record in
the large file that matches the small file. In the BDE version,
simply doing a locate using the ID extracted from the small file
works great. The user scrolls or searched in the small grid and the
large grid follows along. In IBO this works but there is a many
minute delay. Is there a way to establish position into a file
without selecting. Any help would be appriciated. Thanks.

--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 08:10 AM 15/08/2006, you wrote:
> >I have an application that has a table with a little over 3
million
> >records. In the Paradox version the user can enter a record ID,
which
> >is the unique primary key and select that record. The record is
> >selected instantly since the table uses ID as the primary key.
>
> That's not why the record is selected instantly in Paradox. It's
> because Paradox tables and indexes are physical files. Forget
> Paradox. It is chalk to Firebird's or IB's cheese.
>
> >In the
> >IBO version the locate goes off into never never land, puts out a
> >message that says Fetching Query Results - Row # xxxxxx and
appears to
> >be searching the file sequentially. The table's primary key is
the
> >ID. Can anyone tell me what I am doing wrong? The locate can
take 15
> >or 20 minutes depending on the record ID selected.
>
> Everything in a client/server database is based on sets. There is
no
> physical structure to tables. Broadly speaking, performing a
Locate
> on an entire huge table is potentially very costly. Locate() was
> designed for desktop databases like Paradox.
>
> Client/server performance depends on highly economical searches
> restricted by WHERE criteria. IBO implements some work-alike
stuff
> to make sensible Locate() calls on SQL sets feasible. However, a
> Locate() on a set of 3 million records is not even slightly
sensible.
>
> Provide the following:
>
> -- the DDL statement[s] that define[s] the table and its keys
> -- the SQL you are using for the set (unless you are using
TIBOTable,
> of course!)
> -- your KeyLinks
> -- the LOCATE call from your application code.
>
> Helen
>