This could be related with the grid handling code. In another post I already talked about the "SELECT COUNT(*) ..." performance problem, that can only be solved by tuning the code in the grid control itself. If the code is generic, it's a strong possibility it isn't optimized for this, and assumes a count of records taking not time at all. Another strong possibility is the grid control using a SQLite wraper already slow by nature.
I am wondering if there is a possibility of being notified of new/deleted rows without the use of triggers in simple way. What I'm thinking about is in generic database browsers, that want to update their grids if another process changes the database (and a viewer shouldn't create triggers in the database he is watching, only if the user creates one). I know one can register hooks for auth access, but that seems a bit too much and only related to the local process/thread. Another use is for "server" applications, to be notified of changes in the database from local clients (so he could invalidate his cache, etc.). Regards, ~Nuno Lucas P.S. - I'm very weak on SQL, but I think it isn't possible to create temp triggers. Is this right? === On 2004-06-16, Randall Fox wrote === >On Tue, 15 Jun 2004 23:04:04 -0500, you wrote: > >> Hi. We are using SQLite to store and retrieve data rows where each >>row is roughly 2K total in size and in a table of 15 columns. The total >>size of the database ranges from 100-300 MB. >> >> The problem we are seeing is that query and insert performance is >>unusually bad and scales up linearly with database size. Compared to MS >>Access, the query times are several times slower. Frankly I was a bit >>shocked at this considering that most people seem to think the >>performance is good. However, I don't see anything that we are doing >>wrong...we query the rows we want only by rowid. I'm very puzzled that >>this hasn't come up a lot in my searches of the mailing list, but >>perhaps the slower query times aren't a concern for many of the >>applications using SQLite. >> >> Empirically speaking, we display our data in a scrolling 2 >>dimensional grid format. With MS access, this grid responds >>instantaneously when moving through the grid. With SQLite, there is >>very noticable stalling and lag and the disk i/o is higher than MS >>Access by roughly a factor of 10. >> >> I suppose I am looking to see if anyone is seeing the same results >>that I am seeing, and wondering if this is known and expected to be the >>case. The speed results on the website seem way off to me or must be so >>skewed towards a small dataset that they do not apply in a real world >>scenario. I would also like to state that I am very impressed with the >>simplicity of SQLite, which is rare to find these days. It was very >>easy to get up and running. I'm just having trouble getting past the >>performance issues. Any explanation would be helpful. >> >>Richard Kuo > > >How do you fill in the grid control? Is it storing the data, or do >you provide the data when requested? (owner data..) You may need to >implement some caching if it isn't implemented already, I know some >controls have this set up in them, and it could be that either access >is taking advantage of this, or is caching it from w/in the DB >itself.. > >Also, did you implement a integer primary key, and use indexing? > >Randall Fox --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
