--- In firebird-support@yahoogroups.com, "Bob Murdoch" <mailgroups@m.
..> wrote:

>
>
> > -----Original Message-----
> > From: Adrian Libotean [mailto:ladrian@s...]
> > Sent: Friday, June 24, 2005 2:16 PM
> >
> > Indeed. This is the real problem. I display the data (let's say

50,

> > 000) rows in a grid with let's say 10 columns. Now the grid
> > can be sorted by every column in ASC or DESC order. Imagine
> > how this will look for 15 columns where I would have 30
> > indexes that slow down my INSERTS, UPDATES and are very large
> > because I have 50,000 rows.
> >
> > I don't get the reason for this unidirectional approach but
> > to me is a pain in the proverbial arse.
> >
> > Maybe there is another way of doing this, but the nature of
> > the data and of the software application forces me to do this.
>
> This sounds like exactly the situation where you would use a local
> dataset* on the client machine. Pump the 50,000 rows into this
> dataset, and let the user sort, filter, etc on it. Otherwise, even

if

> you had only one column that you would allow the user to sort on,

it's

> still 50,000 rows across the network in ascending order, and 50,000
> rows across the network in descending order on the next click.
>
> *By local dataset, I'm talking about something along the lines of
> Paradox, dBase, DBIsam, etc. If you are using a Borland compiler,

you

> might even get away with a TClientDataset, although I would check

the

> memory usage with 50,000 rows. Heck, you might even use Firebird
> embedded for the local dataset. I would compare the performance of

it

> against the file-based alternatives in this case, as you are looking
> for speed not all the other great stuff that Firebird provides over
> the others.
>
>
> hth,
>
> Bob M..

I didn't say anything about transfering the data back and forth to the
client, that's absurd. I only transfer the rows that are visible (at
most 50) but the DB side needs to sort them using an INDEX not in
memory if I expect performance in a situation where 10 users work with
the database.