> -----Original Message-----
> From: Adrian Libotean [mailto:ladrian@...]
> 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..