Subject | Re: help needed. browsing slows down after a days work |
---|---|
Author | mmenaz |
Post date | 2001-12-11T18:43:25Z |
I've not huge database, and I'm not an expert of performance issues, but I've read a lot of times in this newsgroup about the problem, and the performance penalty, of leaving transaction open for a long time.
First of all, C/S programming is based, for interactive use, of SMALL amounts of data, so you should avoid having something like
select * from MyHugeDatabase
Since it's very unlikely that the user will scroll the grid to see all the 100,000 rows inside.
If he needs to control last inserted/modified records, add a timestamp to the table definition, updated by triggers, and in a regular basis, or at user request, reperform the query
select * from MyHugeDatabase where WHEN_MODIFIED <= '12/05/01 12:15'
If the browsing is read only, set the dataset to read only too (and, maybe, have another dataset chained to the actual record (using master/detail mechanism) for some update).
Consider that IBO, for a select * from MyHugeDatabase, thinks that you really need all the rows from the table, since it's what you have requested. It's wonderful "under the hood" features start fetching all the rows in the background, so your client will be filled with all the rows as time passes. So bad for you!
Just a contribution :)
Regards
Marco Menardi
First of all, C/S programming is based, for interactive use, of SMALL amounts of data, so you should avoid having something like
select * from MyHugeDatabase
Since it's very unlikely that the user will scroll the grid to see all the 100,000 rows inside.
If he needs to control last inserted/modified records, add a timestamp to the table definition, updated by triggers, and in a regular basis, or at user request, reperform the query
select * from MyHugeDatabase where WHEN_MODIFIED <= '12/05/01 12:15'
If the browsing is read only, set the dataset to read only too (and, maybe, have another dataset chained to the actual record (using master/detail mechanism) for some update).
Consider that IBO, for a select * from MyHugeDatabase, thinks that you really need all the rows from the table, since it's what you have requested. It's wonderful "under the hood" features start fetching all the rows in the background, so your client will be filled with all the rows as time passes. So bad for you!
Just a contribution :)
Regards
Marco Menardi
--- In IBObjects@y..., "DennisFantoni" <df@i...> wrote:
> I've gotten this weird bugreport from my customer, and they have
> confirmed the problem is not only one computer, but all of them.
>
> they have an application with an interbase6 server and abt. 20
> workstations.
>
> whe a workstation is on, it shows a ib_grid that connects to a query,
> typically something like select * from table (returning lots of rows)
>
> The application works fine and browsing is quite fast, all considered.
>
> But after 5-6 hours work, brosing becomes really really slow. Perhaps
> 20 times slower than at the beginning.
>
> Does anyone have any idea what this could be? Usually my applications
> start being slow, and stays so ;-) ( or starts being fast and stays
> so..).
>
> Is there something in ibo or interbase that might go slower over time?
>
> the query for the grid loads perhaps 6000 records.
>
> I would like some pointers as to where to look for problems. I never
> used ib_grids before - the other ibobject applications that i made
> were not using db-aware controls. This application was not programmed
> by myself, but the programmer seems to have known the database aware
> objects quite well. Still, he migt've done something wrong that
> causes things to slow down.
>
> My own idea of attacking the problem right now, is to somehow try to
> get the slowing down to occour at my own computer, then to see if
> there's any local memory leaks.
>
> Dennis