On 29 Oct 2010, at 4:52pm, john Papier wrote: > The thing is, I need to keep a cursor to where in the > table I was last searching, so I can continue the search from where I left > off, which is why using multiple tables was preferable; i.e., i can track > the row_id, and then resume the search there (WHERE row_id > cursor_row_id).
This does not work in SQL. There is no concept of 'the order of rows in the table' in SQL and an identical SELECT command is perfectly free to return rows in a different order the second time around. If you want to maintain your own row orders, create and store your own row numbers which do whatever /you/ want. The code for doing this doesn't change much whether you have one huge table or many small ones. Either you create another table to store the maximum current row numbers in or you use the max(id) function to figure out the biggest number you've used so far. I suspect that the most efficient way to do this would be to have one big table rather than many small ones, but I have no proof for your particular application. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
