OP is in windows. Windows can send you display cache hints that tells you what page it intends to display next. I use these notification to load up a page worth of data at a time. Keep it in an internal cache.
>> the ammount of memory needed to store all the rowIDs in could well exeede >> the ammount of memory available to the program. You're talking about 2 gigs in 32 bit windows and virtually unlimited in 64 bit windows. I'd say this is a non-issue. You get the list of RowID's then "SetItemCount" to tell the list control how big it is. Then the user just scrolls/pages up/down resizes as he will. Windows handles the rest. Windows sends you notifications about what data it needs to display and cache hints telling you what data it intends to display in the future. You can use the same technique in non-windows environments like Android. The details change but, the technique works there too. SS> You could set a very big maximum (e.g. 5000 rows) Using the technique discussed here, keeping a list of rowid's to seed the virtual control, I've had virtual list controls with millions of lines of records. It's slowish when I get over about 500K but, functional. It's not really practical to scroll this data but, it works and the RAM usage isn't really over the top. I don't consider using a couple hundred megs for a list control to be unreasonable if that's what the application calls for. Most PC's have more RAM then they can ever use. I think you hit it on head when you suggest that most programmers are mired in the memory limited days. Even android phones can handle 1000's of records in a list control. If it's a list control with only 5000 records, you might be better off loading the entire thing into memory. For my usage, that's a really small list. SS> On 10 Jul 2014, at 12:54pm, - <mz2n6u7c.temp...@xs4all.nl> wrote: >> But it might cause another problem: the database could get/be so large that >> the ammount of memory needed to store all the rowIDs in could well exeede >> the ammount of memory available to the program. >> I could ofcourse use (or at that moment switch over to) a local file >> (database!) to store them in, but somehow that feels a bit odd. SS> You could set a very big maximum (e.g. 5000 rows) on the SS> assumption that users will never actually read or scroll through SS> that many rows. Use LIMIT 5000 and if you actually get 5000 rows SS> returned put up a messages telling them if the row they want SS> doesn't appear they should be more specific in their query. Or some other cop-out. >>> At this point you care only about column values and you >>> never need to use SQL to scroll around in a table, >> >> It also restores the use of the listviews own slider to move about in the >> list (do away with the "page up", "page down" buttons). I must say I like >> that. SS> We're all still adapting to the changes that the excellent GUIs SS> and ridiculous speed of today's computers require. I now have SS> trivial little systems which reflect in realtime changes made by SS> other users and in other windows, just because I needed to write SS> those library routines for my 'big' systems. >> Lastly, the whole of the above ignores systems where the >>> user (or another user !) may insert or delete a row that was >>> in your foundset in another window, while it's being shown >> >> I also thought of that, but wasn't prepared to think about the consequences >> (good or bad) before the preceeding problems where solved. My intended >> approach to it was to add a "reload" button/key (F5) for it. SS> You can deal with cases where the rowid no longer exists (as long SS> as you do correctly test for it). But yes, spotting new rows is harder. >> Thanks for the full (explanation, hints) reply. SS> The clarity of your question suggested that a long answer would be read and understood. >> Remark: I've not seen any reference in your reply to my first question where >> I wondered if it would be possible to refer (in queries) to columns other >> than by their full names. Must I assume its not possible ? SS> Just that I didn't understand the question well enough to answer SS> it and was hoping someone else did. SS> It depends on what interface or shim you're using to access your SS> database. Although several things about SQL syntax betray the SS> fact that columns have an order (for example, you can do INSERT SS> without specifying columns and the third value gets put in the SS> third column) there's no language in SQL to say things like SS> 'column 3' and most APIs don't supply it. SS> On the other hand, if you were referring to the results of a SS> SELECT, then results are always returned in the order you asked SS> for them (apart from *), and you have to go to extra effort to SS> find the names of the columns of the values that were returned. SS> So all you have to do is remember what you asked for. SS> Simon. SS> _______________________________________________ SS> sqlite-users mailing list SS> sqlite-users@sqlite.org SS> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users -- Best regards, Teg mailto:t...@djii.com _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
