Thank you for your thoughts. > You can build the result set into an array, then step through, back and > around the array. > > SQLite already provides this functionality: > http://www.sqlite.org/capi3ref.html#sqlite3_get_table
Having the entire result in memory would be an easy solution but unfortunately it will take up to much memory. I think I will keep an array of rowIds for the entries in the result, sort of a cache. Whenever the user scrolls to a position where I don't have the data, then I will fetch it for him and cache the id. That way it is easy to create random access via the cached rowIds and I only need to store. > The only downside is that you'll have the full result set in memory, even > if you are only using a small portion of it. > > If you want to limit the amount of data at any time, you can use the: > > SELECT ... LIMIT n OFFSET m; > > form of select, where n is the number of rows you want, and m is the > offset you want to start from. For a table view, this may be appropriate, > but you have to recompute the results for each change of page, potentially > slowing your app down for large queries. For the relatively simple tables that we have at the moment, I don't think its an issue to make one lookup per item when scrolling. But tests will show that. > >Cheers > >Kim B.
