Select some fields from your table, don't load them all.
eg
with QueryGrid1 do begin
     Close;
     SQL.Clear;
     SQL.Add('Select Num, FirstName, LastName from "C:\..\myTable.dbf";');
     Open;
end;

with DataSource1 and QueryGrid1 as TDataSource and TQuery for your TDBGrid.
(Don't use order by if there is no index on it)
(but as Michael said: Query.Last takes time)

Rudy
===========================================

blacklungs schreef:

Have you calculated fields? Do you use indexes? Is the paging good?
Do you use Prepare? Do you use order by in your SQL? ...
Paradox, dBase, InterBase, or what kind of database?
Show us your SQL (select ...)

I make weekly a backup + restore database (make them 10 times faster!)

By the startup I always search some records from a table,
after this, all the queries works very fast.

Rudy
============================================================
blacklungs schreef:

1. Use a TTable instead of a TQuery.  This often works well if you're
reading most of the columns of a table.  Not usable if you're trying to
order the results in a way that doesn't correspond to an index.

2. Use a TTable connected to a view defined on the database server.
Like method 1, but lets you limit the set of columns retrieved.  Works,
of course, only with a SQL-based database.

3. Use a TQuery which retrieves only the primary key from each record.
Add lookup or calculated fields for each field you want to display in
the grid, retrieving the data from another dataset pointing to the same
table.  The result can't be made editable in the grid, though if you use
calculated fields and position the auxiliary dataset in the OnCalcFields
event handler, you can hook single-record data-aware controls to it.  If
you need to search in the dataset, use a query or stored procedure to
retrieve a primary key for the record you're looking for, then a Locate
to reposition the keyset dataset.

I've often claimed that tables give better performance than queries with
SQL engines, but method 3 gives the best performance I've seen for
general browsing, if you're willing to deal with the extra complexity.

What I am saying is that I can't change the dataset that I want to get.
I am just wondering if there is a faster way to get the dataset.

Maybe I should rephrase my original question:

Task:
    1. I need to select columns a, b, c, x, y, z from a table K.
    2. The table has 10000 records, and I need to display ALL of them in a
scrollable control.

Problem:
    1. The method of using TQuery and TDBGrid is too slow.
    (if I execute TQuery.Last right after TQuery.Open, then it's too slow in
the beginning, and if I don't it's slow when the user is scrolling/browsing
the records)

Try connecting a DbGrid to a TTable that has a specific index
activated (i wouldn't rely on  field-name indexes) and see if the
performance is any better.

If this doesn't work you'll probably have to rethink the problem, does
the user really wants to navigate through 10k records with a
scrollbar?

NB: You haven't stated what sort of Database (Local, Interbase, ...)
you are using. Keeps us guessing a bit.

-hh-

tquery is only a good way to find records not to display a great table in a
DBGrid (not SELECT * from XYZ--> that's like searching in a phone-book). If you
must give the wholy table to an DBGrid the first choice is TTable over to
TDataSource to TDBGrid.
If you must search use TQuery (if the user only gives an 'A' to search for give
him a Phone-Book), if you must display only without filtering data use TTABLE
TDATASOURCE.
Otherwise if the user wants to filter out 10000 records out of a table I think
SQL is not powerfull enough to do that. but there isn't a more powerfull tool
yet.
Or try to write the TQuery.First to Last in a seperate Table to display the
table later in the DBGrid.
Another way is to close all other functions that are using the table the dbgrid
when scrolling (like other calculating). Use index in rows you are using mostly.
when you are delete, insert, edit records index make the performance slower. for
that you can you can inactivate the index with:
Alter Index<IndexName> Inactive.

Hope I don't misunderstand the question an it helps.

Bye Dirk.

blacklungs schrieb:

About 10000 records right now, expected to increase over the years in
approx. 1000 increments.

The database is Orace 7.3.2.0.0, remotely connected over a 56KBps frame
relay line, through a firewall.

Vielen Dank,

Vielen Dank,

I suggest you have a nice talk with your user and try to explain this
well to him/her.  Do your calculations correctly beforehand and show
your user some *facts*.

You could either provide for selection of small quantities of records
or (if they are always interested in those last records) reverse order
the query.  You should really be *glad* that BDE optimizes the data
fetch operations.

Regards,

blacklungs schrieb:

Bye Dirk.

What I am saying is that I know the with the current network setup the query
takes a long time.
But it's taking a lot longer than the estimated time that I calculated with
about 70 bytes a record (this being generous, actually) which is about 700K,
and calculates to around 100 seconds assuming 100% line usage.

Anyway, I finally made the user decide not to do it his way.

With a new query, the fetch operation is reduced to about 50 records!

Thanks for all the help, despite my mediocre explanation of the situation,
everybody.

regards,
Jay.

        Bye, Luca.