If I have a html home page with a search function that when submitted

activates Inet_GetRecs.

Inet_GetRecs does a RList for the search words saving in a syslists item time*date (Request).

If items are found then Inet_GetRecs calls Inet_SearchResults

with HtmlVar=Inet_SearchResults(Request).

Inet_SearchResults gets the list, Call Activate_Save_Select(Request),

and processes.

How do I delete the save-list ? Or more appropriately when?

I am doing it this way so that in Inet_SearchResults I have a "Next" and "Previous" link which calls Inet_SearchResults again and appends a page number onto "Requests" (parses the page number to get the original ListName) and then calculates which item ids to read and process on.

It seems that this will create alot of items in SysList for each iuser

using the search.

I could write a routine to delete the lists at some point but unless I checked the date and time I would not be positive that someone was

not using a saved list.

Am I way off base here or missing the obvious?

Thanks

Bruce,

Near as I can tell you have to create a clean-up program that either gets run at periodic intervals or it is constantly running and monitoring your SYSLISTS table.

Obviously this is one of the challenges with a Web based access. There is really no clean way to know when the user is finished browsing your database. Fortunately it seems that most sites with CGI generated pages use some form lifespan for these documents and then they are removed. The same principle should apply to your select lists as well.

dbakke@srpcs.com

SRP Computer Solutions

Bruce/Don,

What about letting the user do the clean-up? What I think of is: Each time a new item is created, delete an old one.

(Perhaps there is less overhead with Don's alternatives, because clean-up can be done during quiet moments. But I leave that to you.)

I can think of two main approaches:

(A) Either literally do that - each time a new item is created, delete an old one.

(B) Or have one or more circular lists of items, which are re-used.

(I imagine the overhead will be the same.)

(A) will be like you're on a road (SYSLISTS), laying down new stones (items) in one direction, while at the same time removing stones from the trailing end. With (B) you are on a circular road, with a circular trail of stones, moving from stone to stone in one (circular) direction.

In my web app I have chosen (B).

The main idea is to have items with names that include a sequence number. Each new item gets the next higher number. When the number reaches a certain limit, I go back to 1 again.

I have not explored how to implement (A). Perhaps one could again use sequence numbers, but instead of having them go in a circle, just let them grow. And each time a new item is created, delete the oldest one. The oldest one will have a sequence number equal to the current number minus a fixed amount.

In my variation of scheme (B) I have a (rather small) circular list of items for each IP number. If there are a limited number of IP numbers accessing the database, there will be a limited number of items in all, with no need to purge.

But in many cases (also mine, eventually) there will be a lot of IP numbers, and a lot of items. And if users are accessing via ISPs, they may get new IP numbers each time, resulting in even more items. Then it's better to let the app have a login and use a circular list for each user name instead.

And if there are very many user names also, one could perhaps let the system allocate re-usable user ids instead, and have one circular list per id.

One possible problem with this approach is that a user might want to access a list that has been overwritten. So when accessing an old list it's necessary to do some date/time checking. If the list has been overwritten one can issue a warning, telling the user she will have to run the query again.

Perhaps (A) has an advantage over (B) because it's easier to check if an item is too old. Too old items are simply not there. One doesn't have to bother with remembering and checking date/time.

I have also toyed with the idea of having one, large list - one list for all users. There are problems, but perhaps they can be overcome.

How do I delete the save-list

There is a Delete_Save_Select subroutine. Can't you use that?

- Oystein -

Here is one possibility:

1) Create a table (say, USER_LIST) for user list IDs. Each user has a row (with the user ID as the key). When a user performs a search, the script checks USER_LIST for the user ID. If the row does not exist, the script creates one and stores the save-list ID as field one. If a previous save-list ID exists, the script can be set to use the old save-list ID as a key to delete the old keylist in SYSREPOSLIST - or - as an option, allow the user to use the existing list in lieu of a search.

After using REDUCE or RLIST to create a new keylist, the script then automatically stores the save-list ID in the user's row in USER_LIST. Heck, you could could even add a couple of fields to time-date stamp the list ID.

The proposed USER_LIST table only holds the save-list IDs (with user ID row keys), not the entire keylist.

The USER_LIST table adds user rows only as a new user requests a search.

Another advantage is that you can use your current save-list ID creation scheme.

Thanks for the responses.

I think I will take pieces from all the suggestions.

I believe I will have an item in my appctrl table that

'pushes' save-list ids on and 'pops' off the oldest (after

checking the date) and deletes from the syslists table.

Eg. inetsavelists=nnnnn*nnnnn^nnnnn*nnnnn^nnnnn*nnnnn

Thanks again.

Maybe something like this….

 TimeDateId=Time():"*":Date():"*0"

 ListName=TimeDateId 

 Read SavedNames from CtrlFile,"INETLISTNAMES" Else SavedNames="

 If SavedNames # '' Then

    Chk=SavedNames

    ChkDate=Field(Chk,"*",2)

    If ChkDate =ListName

 Write SavedNames on CtrlFile,"INETLISTNAMES" Then

 End

View this thread on the forum...