Am Freitag, den 29.06.2007, 23:09 +0200 schrieb Frank Schönheit - Sun Microsystems Germany: > Hello *,
> > 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 > > Which implies the first result set also needs to have the keys. Also, > not sure it would scale for searches over all fields (well, most > probably better than today's solution). Not to mention the second result > set could have different data in a multi-user environment. Anyway, all > this is nitpicking :), it general it would work. Hm, I didn't think about views or "keyless" queries here ... how does the current implementation work, maybe tuning the client side search algorithm or changing the view update policy (only every 10th or 100th value) could help a lot? > And, it's similar to a technique which at least one generic DB API, > namely ADO, already provides: It is able to specify a search criterion > (aka WHERE condition aka filter) for an existent result set, and then > move this result set to the matching record. I always thought about > using something like this, unfortunately, there ain't many backends > which support it. And implementing it for MSA DBs only doesn't sound too > reasonable ... > > Anyway, the solution you sketch could even be used to simulate this > approach transparently, and it would work for a sufficiently great > percentage of cases. It would be helpful to know how other clients do it. And if it is more costly regarding execution time to search locally or requery from the server. > Sounds tempting. Perhaps after the macros in Base documents? Or the > zillions of bugs targeted for 2.x, lingering in my intray? Or the UI for > HSQL text tables, planned and started long ago? (End of begging for > compassion. Well, September next year my "parental part time" at Sun > will be reverted back to full time, I'll probably have more time for the > interested Base issues then, though less time for the interesting :) I'm standing by your side if it's about avoiding useless work. The best thing would be to make it easier for anyone to roll up her sleeves and fix issues or implement features by herself. Seems to be the only way of lowering the workload of the dba team ... Marc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
