Am Freitag, den 29.06.2007, 09:58 +0200 schrieb Alex Thurgood: > On Thursday 28 June 2007 20:40:04 andrew wrote: > > Hi Drew, > > > > Well, no. I am talking about using the search function. That is not SQL > > based, instead it iterates over the result set looking for the first > > match, and it is all on the client side. > > > > Here is a specific example. I have a table that consists of 21 fields, > > all of type integer or double. The table has 10,000 records. This is a > > HSQL embedded database, it is running under XP on an AMD 3300+ processor > > and 640Meg Ram. The table has a primary key field of type integer, and > > is fully packed ( meaning there are keys from 1 - 19,999 ). > > > > I open that table in a data view and place my cursor in the PK field. I > > then open the search box ( click on the binoculars ) and enter a search > > criteria of 2000. Now what would be an acceptable time for that search > > to find a match - I'm not sure, but I am relatively sure that what I get > > is not an acceptable time - on average 74 Seconds. > > Tell me about it :-( This problem has existed for as long as I can recall, > irrespective of the db. I've had this with DBFs, mysql, HSQLDB, so the > problem is definitely with OOo or the way that it executes the search > function.
Hit by those numbers I did some quick testing (never having used the looking glass before ;) and found you're right, it is OO.o. Testing two different databases the behaviour is nearly the same. Those databases have been one internal HSQL and one MySQL via a network line on a table having a lot of dates and floats and an alphanumerical primary key. Other selcting techniques (filter, sql) are fast as expectd, regardless which database is in use. In other words, in general internal HSQL databases are fast enough for every day use. Concluding the implementation underlying the search dialog is the spot. But in general this dialog has a task much broader than only searching primary keys, it can use more fields than one an a lot of search criteria combinations, ... IMHO one implementation getting this thingy faster could be to combine both, a result set over all records and a query for searching. This query works fast getting the key(s) and the full result set can be used for showing the findings (dunno how multiple search results are presented, will check later). That would allow both, fast searching and result browsing while seeing all records. Marc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
