Hi there,

We have a very large LISTS table and for ease of maintenance we would love for SAVELIST,GETLIST and DELETELIST working of a different table to the query table ie. SAVEDLISTS rather than LISTS.

This way we could just clear LISTS and retain our saved queries.

I have a LISTS MFS which does the job, but is a bit hairy.

Is there another way?

Phil.

Heres my MFS:

SUBROUTINE LISTS_MFS(CODE, BFS, HANDLE, NAME, FMC, RECORD, STATUS)

FSLIST=DELETE(BFS, 1, 1, 1)

NEXTFS=FSLIST

IF CODE LE 6 AND NAME NE "" THEN

IF NAME1,11 NE "QUERY.TABLE" AND NAME1,13 NE "COMMAND.STACK" THEN

IF NAME1,"." MATCHES "2N':'2N':'2N'**'2N'*'3A'*'4N" ELSE

 OPEN "SAVEDLISTS" TO HANDLE THEN HANDLE=HANDLE ELSE NULL

END

END

END

IF NEXTFS THEN CALL @NEXTFS(CODE,FSLIST,HANDLE,NAME,FMC,RECORD,STATUS)

RETURN

Phil,

SAVELIST filename listname

Lists are saved to the LISTS file implicitly when the SAVELIST command contains only two elements.

Bill

There are two things you can do. First, you can write a program (like what we did) that goes thru the LISTS keys and looks at the keys. The system creates it's keys for this table in a particular way/format. Part of it holds a date/time stamp. Our program looks at the key, if it matches the system format then we continue to look at the key otherwise it's most likely a saved list and leave it alone. Of the keys that match the format of the system generated keys, look at the date part of the date/time stamp, if it's a date for yesterday or older then it can be deleted. You might want to look at the date/time stamp and see if it's older than 24 hours from now then the row can be deleted. This avoids any system generated lists that may be in use at the time you run your clean-up process.

As for the user saved lists that are still hanging around, it's been my practice to work with the users in determining which need to stay and which can be deleted.  I generally create a temporary table, copy all of the rows from the LISTS table into that,  clear our the LISTS table, copy the rows the users indicated that they want kept back into the LISTS table.  Then in  a week or so, if I haven't gotten any calls saying that someone needs a saved lists restored, I clear out the temporary table and delete the table.

The second option is to set the number of saved queries to zero (0). This is part of the configuration of the application. I don't feel it's my place to tell you how to do that. You need to discuss that with your AREV Administrator. If you are the AREV Administrator then I'll let you talk to someone much more knowleageable to help you thru setting that and any issues that may go with it.

I hope this helps.

Michael Slack

Some time ago I wrote and MFS and associated utilities to keep track of LISTS. Such information as create date/time, usage date/time, creator, number of records, etc. were maintained. A user interface allowed users to view only their own lists or lists of others.

As part of this project, I built in the ability to clean up query lists. I haven't used it in a long time, but if there is some interest, I might still find it.

By god you are right, a decade of Arev and I learnt something new!

SAVELIST filename listname (opt) is not in the manual.

Shame I cant default the table for SAVE/GET/DELETELIST to SAVEDLISTS rather than LISTS is way I wont have to change every program which use these commands and we wont have to remember to state the tablename.

I guess I could just write my own save/get/deletelist programs which in turn pass SAVEDLISTS to save/get/deletelist_sub as the tablename.

Perhaps you could use the SETALIAS command:

SETALIAS location application SAVEDLISTS LISTS

Check the documentation for the complete command string with parameters.

Bill

Beware of doing this kind of stuff to system tables. There a lot of hard-coded assumptions buried in many places. For example, I'm not sure that the aliases are available when AREV initially starts, yet there are commands saved in the command stack. JAT ..

Don M.

Don,

True enough. Thanks for the reminder.

Bill

Actually changing characters LISTS to SAVED (ie 5 char only) in $V1,$V2 and $V35 achieves the desired affect but as I want to use SAVEDLISTS..

I think the cleanest way to achieve this is to write my own save/get/delete functions thus:

SUBROUTINE LISTS_SUB

DECLARE SUBROUTINE FSMSG,MSG

SENTENCE=@SENTENCE

CONVERT @LOWER.CASE TO @UPPER.CASE IN SENTENCE

PARA=TRIM(SENTENCE1,"(")

OPTS=SENTENCECOL2()+1,")"

ACTION=FIELD(PARA," ",1)

IF COUNT(PARA," ")=2 THEN

TABLENAME=FIELD(PARA," ",2)

LISTNAME=FIELD(PARA," ",3)

END ELSE

TABLENAME=SAVEDLISTS" ;* new default table

LISTNAME=FIELD(PARA," ",2)

END

BEGIN CASE

CASE ACTION=SAVELIST"

IF @RECCOUNT THEN

 OPEN TABLENAME TO F.TABLE THEN

  CALL SAVELIST_SUB(TABLENAME,LISTNAME,OPTS)

  MSG("W166","","",TABLENAME:@FM:LISTNAME)

  IF COUNT(OPTS,"A") THEN @SAVE.SELECT=1

 END ELSE FSMSG()

END ELSE MSG("S142")

CASE ACTION=GETLIST"

IF @RECCOUNT AND COUNT(OPTS,"O")=0 THEN MSG("W383","",CONT) ELSE CONT=1

IF CONT THEN

 OPEN TABLENAME TO F.TABLE THEN

  READ ROW FROM F.TABLE,LISTNAME THEN

   CALL GETLIST_SUB(TABLENAME,LISTNAME,OPTS)

   MSG("S144","","",@RECCOUNT)

   @SAVE.SELECT=1

  END ELSE FSMSG(LISTNAME)

 END ELSE FSMSG()

END ELSE @SAVE.SELECT=1

CASE ACTION=DELETELIST"

OPEN TABLENAME TO F.TABLE THEN

 READ ROW FROM F.TABLE,LISTNAME THEN

  CALL DELETELIST_SUB(TABLENAME,LISTNAME,OPTS)

  MSG("S145","","",TABLENAME:@FM:LISTNAME)

 END ELSE MSG("B166","","",LISTNAME:@FM:TABLENAME)

END ELSE FSMSG()

END CASE

RETURN

Still testing this but looks good.

You could always put LISTS files in different volumes and use attachtable commands to change locations.

Should be quite safe. Looks pretty good to me. Good job.

Don M.

That would seem to be unworkable. Consider that you would have to do something along the lines of:

ATTACH Query_volume

SELECT Filename with …

ATTACH Getlist_volume

SAVELIST Savelist_name

Why not divide the lists files up by groups of users? That way there would be smaller lists files to contend with.

If user in groupA -] attach listsA etc.

Distribute the power users (generating the most or largest savelists)between the groups. In a nightly process clear the group lists files on a rotating basis either by day of week or from julian calendar day. No matter how you spread a pound of butter it's still a pound of butter.

Prime Information used to time stamp all entries in the LISTS file generated by system processes and you could clean out the LISTS file periodically manually or with the CLEAN.ACCOUNT verb.

"For every problem that is complicated, difficult and obscure there is a solution that is simple, easy and wrong" - Santyanna

I just attach a different LISTS table for us development guys, coz we are the ones using very large lists with various names not the users.

I also reduced all query table sizes and they clean themselves up.

View this thread on the forum...