Subject Re: tib_grid performance
Author mmenaz
I'm not the most qualified person for an answer (Helen, are you lissening? ;) but since you don't have a reply...

> The user needs to see many records with the
> ability to scroll.
As often highlighted in this forum, grid with many records=bad C/S design = Old Paradox/Dbiii file server design = don't make sense.
With something like
select * from orders
in Paradox you are telling the engine: Open the file and position to the first phisical record
In a true C/S system you are telling the engine:
ehi, I DO need those 10,000 records! Prepare the dataset and give me back the first 20 rows to display (grid), but i need ALL the dataset.
In this case, IBO is so smart that fetches only the needed rows for the grid and in background tryes to get the rest of the resoulting dataset with the lower impact on your app.
Is really the user need to have ALL the dataset, simultanuesly on the grid? Can't you provide some search criteria to refine the select? (i.e. oder_date>'01-02-2001')

>
> The problem is the performance. When I first bring up the screen and
> click the last button in the navigator bar, I get a "fetching query
> results" dialog box.
Yeah, gimmi ALL the dataset, please, Interbase..
Did you set "AutoFethAll" to true? Set it to false.

> When I click on the title of the other column in
> the grid to re-order, I get the same dialog box.
Yeah, ok, I was jokin, that's not the order I need... reorde the dataset and give it me it back again, Interbase...

> If I add the POS=0
> to either or both orderinglinks, then I will get a "fieldname not
> found" error when I try to sort on the other column. The POS=0 works
> when there is only one orderingitem.

Sorry, don't know. I know that if you want to take benefit from the 'straight to the last record' you need indexes, in reverse order too, upon the main key field, but search the list of the online faw (www.ibobjects.com) for details.

>
> I have tried using schemacache, but that doesn't work. The bde
> version works well.

You are comparing apples with oranges :)

> Changing the user interface is not an option. I
> have asked this question before, but have received no answers for
> multiple orderinglinks.
If you want to go to C/S, you have to change something in order to preserve performance. Think about 20 clients that are retreaving for the server the 10,000 record only to press the "last" button and go to the recent ones... does not make sense. In SQL you don't have to deal with phisical archives, it's all "virtualized", with pros (many) and cons (few). It's just a matter of getting used to this way of thinking (I had and I have to convert my mind, but it's the right thing to do :))

> It doesn't seem right that the bde does
> something so much better that ibobjects.
Belive me, IBO is so better optimized that nothing can give you better performance even in wrong designed situations. Of course, you can't do miracle since C/S is not a joke. So it's not IBO fault, it's a matter of C/S logic.
But maybe someone else in the list can help you fine setup IBO so the impact of the design will be smaller that the one you now have.

Regards
Marco Menardi