I understand and agree that things changing in the middle is not ideal. In the situation I am dealing with, things MUST disappear in the middle of the dataset. As far as adding things, it should happen at the end, but that is outside of my control, it all depends on how things are sorted. Normally things will be added to the end of the dataset, though.
I take it that there is no solution to my problem? Sam On Mon, May 25, 2009 at 4:53 PM, Teg <t...@djii.com> wrote: > Hello Sam, > > Are you planning on periodically updating the display as the user > interacts with it? Have items pop in and pop out again as they're > added or deleted? From your description, the data displayed in the GUI > will go stale very quickly. I actually have similar logic in my app > and I always append new things to the bottom so, it doesn't affect the > current displayed page. Nothing annoys me more than to have items > dynamically appearing and disappearing while I'm trying to interact > with a GUI. > > > > Monday, May 25, 2009, 4:32:56 PM, you wrote: > > SC> On Mon, May 25, 2009 at 4:05 PM, Teg <t...@djii.com> wrote: >>> Hello Sam, >>> >>> Paging or scrolling is purely an abstraction you create with the GUI >>> itself. If you load up 88 titles into memory and your screen display is >>> 40 lines then you have 3 "pages" in memory and you simply replace a >>> "page" each time they scroll or page up/down. You seem to be letting >>> the back end dictate what the GUI does when in fact it's better to >>> abstract the whole thing so, you can change the back end at will and >>> not have to change the GUI. For 88 items, I doubt I'd even use a DB. >>> Nothing beats a flat text file when you have a tiny data set. > > SC> I hear you that paging should be frontend logic, normally. The > SC> problem is that I have a *DYNAMIC* record set that is constantly > SC> changing: > > SC> The nature of the dataset is that it can grow very quickly early on > SC> and at any point after that rows can be deleted through out. It is > SC> this last fact that I need the help of the backend to figure out the > SC> page. > > SC> Assume 5 items per page. If there are 88 items in the record set on > SC> one call that returns 50 to 55, before the next call, items 3,12, 17, > SC> 32, and 42 are all deleted from the record set, Item #55 is now going > SC> to be #50. If the front end is simply giving the backend an unique > SC> identifier of the item, not the PK, per the recommendations of the > SC> ScrollingCursor page, how does the front end learn that it now is > SC> getting #50 through #54 rather than #55 through #59? > > SC> Further, I am assuming this is a problem with paging on any dataset in > SC> any database, thus a backend issue :) > > SC> Sam > > > > -- > 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 > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
