I need to know more about SYSLISTS.

What I want to do is to

(1) save and reactivate lists

(2) …including lists that don't come from queries

(3) save and reactivate queries (even if I might not consider SYSLISTS for that)

(4) handle large lists (maybe chop them up in smaller parts than 32K, so each part can be shown in a popup).

I need to know basic stuff like

(a) what kind of rows and fields are in SYSLISTS

(b) something about SYSLISTS row names (e.g how I should name lists if I save them by name)

© something about maintenance (e.g when are old rows purged)

and perhaps the not so basic answer to the question of having more manageable parts when the lists are large.

I have been able to find out a few things by myself, like there seems to be three kinds of rows - "Q", "W" and "T". There seems to be separate sets of rows for the different combinations of user and station. "Q" is for the last query, "W" is for various lists (some are referred to by the "Q" rows), and the "T" rows is a set of temporary lists that is reused. I have figured out the various parts of their keys.

Is there any suggested reading? Or can anyone spare a few minutes to give me an introduction?

- Oystein -

Oystein,

(1) save and reactivate lists

There are several routines that makes this easier to work with in OI than in AREV, although the principles in AREV are still applicable to OI. In the PRG look at Save_Select, Active_Save_Select, and the related links.

(2) …including lists that don't come from queries

I believe the above will help you.

(3) save and reactivate queries (even if I might not consider SYSLISTS for that)

I'm pretty sure SYSLISTS has to be involved somewhere, although you could store your lists in a separate table, read the record, and then apply necessary code to reactivate the list.

(4) handle large lists (maybe chop them up in smaller parts than 32K, so each part can be shown in a popup).

Again, like AREV, OI will break up a select list into multiple records using an appended "*" and an integer as a part of the key. However, unlike AREV, OI will start the integer at 1 wheras AREV starts it at 2 (or is it the other way around?).

(a) what kind of rows and fields are in SYSLISTS

They are @FM deliminated keys.

(b) something about SYSLISTS row names (e.g how I should name lists if I save them by name)

For Basic+ routine purposes they can be any name you choose. If you are trying to retrieve a saved query I'm not sure what the structure of the keys are.

Is there any suggested reading? Or can anyone spare a few minutes to give me an introduction?

Note that RList will create a select list for you and it will store comments as well regarding this list. Also look at the routine Make.List, another goody brought over from AREV. This will take an @FM delimited variable and create an active select list (cursor 0) out of it. From there you can perform normal ReadNext operations or engage the Save_Select routine to store it away.

If this isn't very helpful then provide a more specific scenario and I'll provide some tips on what to do.

[email protected]

SRP Computer Solutions

- Oystein -

Don (and others who are interested - please feel free to join in),

I knew most of what you wrote. I should have been more specific. I'll try to be now. Here are some questions, observations and thoughts.

About how to name lists saved to SYSLISTS (or to any common table for that matter)

Even if one can choose whatever name one likes, one might need a scheme to distinguish between lists belonging to different users. So if ownership is not reflected in the name of the list, something else must keep track of which lists belong to whom.

To me it seems a good idea to have the user id in the name of the list. That is what OI does for lists it names itself. All SYSLISTS rows for "un-named" lists have keys containing user id. The general form of SYSLISTS row keys seems to be:

• ***

I think I might adopt a similar naming convention. Except that there is…

One possible problem with how OI names SYSLISTS rows:

There is a possible flaw in OI's naming convention. The names don't contain the application name. So if two apps have users with the same name, and those apps are run from the same station, there can be a name conflict. (So now there might be a conflict for "Q" and "T" rows.)

Where does the comment go?

The Save_Select subroutine has a fourth parameter . Where does that end up? I cannot find it in any of the SYSLISTS rows produced when I run Save_Select.

Sequence number peculiarity

Another observation (but no problem): Long lists are divided into several rows with a sequence number as the last part of the key. But there is a peculiar difference between "T" rows and other rows: The "T" rows are numbered '*1', '*2', etc, but the other ones have a first row without any sequence number before continuing with '*1', '*2', etc.

Is Arev different again? No wonder you didn't remember.

The "Q" rows

I don't quite understand the SYSLISTS "Q" rows. Experimenting now it seems that when I run RList SELECT's and Save_Select's, new information accumulates in the current "Q" row. But when is it purged? Because if it never was purged there should be lots more in my "Q" rows from earlier.

On the other hand I don't know if I need to understand the "Q" rows. At first they looked to me like they might be used to keep track of saved queries, but perhaps a dedicated table is better. Perhaps the "Q" rows cannot be used at all. It seems that when you save a query with your own name, the "Q" row doesn't remember the name (key) of the saved list, but the key the list would have got if you didn't name it yourself (i.e, a "W" key).

Large lists

My problem is that even if OI does chop large lists in smaller parts, the parts are too large to handle. I want to show the result of a query in a popup, but the popup has more fields than just the key, so the amount of data easily becomes too large for the popup.

In the current version of my app I have just set a fixed but relatively safe limit to the number of keys in a result list. If the search returns more than 2000 rows, the user gets a "Too many hits" message, period.

What I hope is possible is to handle large lists with some kind of paging mechanism, but the parts or pages must of course be smaller than what SYSLISTS is using. Such a paging mechanism could be implemented in different ways. The user might be aware of the parts or pages, or it might be hidden from him. But in either case I think it would be easier to implement paging if the table where the lists were stored, and the functions accessing that table, directly supported the smaller page size.

So my first question about large lists is: Can SYSLISTS have smaller list parts?

If not I have to use a dedicated table. But that adds a time and storage overhead. As far as I understand every list generated now results in two copies in SYSLISTS - the "T" row(s) and the "W"/named row(s). Using a dedicated table means a third copy. So my second question about large lists is: Can I somehow reduce the number of copies?

Saving and reactivating result lists and queries

Some clarification about saving and reactivating result lists and queries:

I have made my own query windows where the user fills in search criteria in fields and radio buttons. When the user presses a "Search" button, a SELECT query is made and run.

In such a scenario there are two possible things a user might want to save for later - the result list, or the query. The reason for saving queries could be that there are some standard queries that are used on a regular basis, e.g, for a monthly report. But in what form should queries be saved? They could be saved as SELECT commands (as in the SYSLISTS "Q" rows), but in my app I instead save a snapshot of the filled-in query window - an array of control names and values. In this way I can bring a saved query forth in the query window again, so that the user can validate and/or modify the query before executing it again.

Today I use a dedicated table for saved queries, and I need to know more about SYSLISTS before I can decide if the latter is better.

(In my query windows I cannot save and reactivate result lists, but that is only because I haven't had the time to implement it.)

- Oystein -

Oystein,

I knew most of what you wrote. I should have been more specific. I'll try to be now. Here are some questions, observations and thoughts.

I figured you must have, but one never knows. Since I don't do a lot of custom management of SYSLISTS entries I'm not going to be much help with the bulk of your questions but I'll chime in where I can.

Where does the comment go?

I've never used Save_Select's comment parameter but RList has a comment parameter and the first field position will hold it. How it get's ignored as being a part of the select list I'm not sure. I didn't look at it very carefully but perhaps there is a delimiter in front of it.

Can SYSLISTS have smaller list parts?

Yes, as long as you name your related SYSLISTS record appropriately

[email protected]

SRP Computer Solutions

Oystein,

The Q* and T* lists are generated and managed by the system. The Q* lists are for previous queries and the T* lists are temporary lists used to load and page cursors.

You are welcome to name your lists in any way you desire, but I would suggest that you not prefix them with prefixes that you see the system using.

Cameron Purdy

Revelation Software

Don,

]]]

]

You are right about RList (i.e the parameter works

and there is a delimiter in front). Thanks a lot!

I have never noticed that parameter.

But I don't understand why Save_Select with a

comment parameter doesn't work as well. (I think

I'll make a new posting about just that.) (Am I

difficult now? )

]]]

]

Do you mean that if I make smaller parts OI will

treat them correctly?

But do you also mean there is a setting or parameter

somewhere I can use to get a smaller part size,

either for all lists or for each particular list

that's made/saved?

- Oystein -

Oystein,

But do you also mean there is a setting or parameter somewhere I can use to get a smaller part size, either for all lists or for each particular list that's made/saved?

You don't "get" parts. You get keys from a cursor using the BASIC+ ReadNext statement. You get the cursor from Activate_Save_Select.

Cameron Purdy

[email protected]

Oystein,

Do you mean that if I make smaller parts OI will treat them correctly? But do you also mean there is a setting or parameter somewhere I can use to get a smaller part size, either for all lists or for each particular list that's made/saved?

The former. That is, if you are creating your own save lists and are programmatically writing them in SYSLISTS, they can be any size you want (bytes wise) as long as you name them appropriately (e.g. LISTS, LISTS*1, LISTS*2, etc.) so that whatever retrieval system you are using (e.g. Activate_Save_Select) knows to link them altogether.

Nothing that I know of that creates savelists automatically (i.e. RList or Save_Select) can be set to create smaller sub-lists in the SYSLISTS table.

[email protected]

SRP Computer Solutions

Don,

Thanks a lot!

- Oystein -

Cameron,

Thanks for the clarification.

I now know where to go from here.

As I said I wanted to treat long lists in manageable chunks -

let's say a few hundred or a thousand keys each.

So I thought if OI could support chunks of that

size I'd get less overhead retrieving them,

and easier programming. But perhaps the gain in

efficiency wouldn't be that much.

(But could you please have a look at my

Save_Select question?)

- Oystein -

View this thread on the forum...