Hi All

I have a series of RLIST statements in a program that progressively refine data entered by the user.

RLIST number one returns 72635 records

RLIST number two hangs instantly

I have tried this from System Editor Line as well as from program and either way the second RLIST hangs, I get 'oengine not responding' from ctrl+Alt+del on Win95 as soon as I execute the second RLIST.

Is there a way around this?, What is the size limit on an RLIST result?

Do brackets work in RLIST statements eg

for the following statements:

Sel1=SELECT my_table WITH TRANS_DATE < "6/6/2000"'

call RLIST(sel1, 5, ,,) Sel2=SELECT my_table WITH MY_CODE=APPLES", "ORANGES"' call RLIST(sel1, 5, ,,)

I know that if I combine this without brackets eg

selx=SELECT my_table WITH TRANS_DATE < "6/6/2000"'

selx := ' AND WITH MY_CODE=APPLES", "ORANGES"'

I effectively get the following bracketing

SELECT my_table (with TRANS_DATE < "6/6/2000" AND WITH MY_CODE=APPLES") OR (WITH MY_CODE=ORANGES")

ie all the oranges with any trans date together with any apples which happen to have a trans date before 6th June

When what I want is

SELECT my_table (with TRANS_DATE < "6/6/2000") AND ¹⁾

ie all the apples and oranges with a trans date before 6th June.

Scott

Scott,

Have you looked at the REDUCE routine. I believe RLIST is basicly a shell round the likes of REDUCE.

That the RLIST statement crashed sounds like A) some defective data / key or b) defective syntax.

Scott,

Try without the comma. Not

WITH MY_CODE=APPLES", "ORANGES"

but

WITH MY_CODE=APPLES" "ORANGES"

- Oystein -

OpenInsight does not handle selects the same way as ARev does. OK, that's not quite true. Let's try again…

OpenInsight does not handle selects the same way as most versions of ARev. OK. That's better.

OI works on the select logic of ARev 3.0 or 3.1, can't remember when RTI made the change. Think it was 3.0. What happened was they changed the logical AND/OR precedence to move it more into the mainstream of selection logic. Basically, they changed from standard PICK constructs to standard SQL constructs. ARev 3.12 went back to the original standards, but OI had moved to another code base and was never changed. There were valid reasons for this, but needless to say, ARev and OI effectively handle selection criteria differently.

With that, the safest course of action is to always place all criteria in parentheses (brackets) and use all the AND/OR constructs required. You should not rely on any implicit formatting especially if you are sharing programs with ARev.

The Sprezzatura Group

[/i]World leaders in all things RevSoft[/i]

Mr SG,

Basically, they changed from standard PICK constructs to standard SQL constructs.

Could you take two seconds and show what a Pick construct is versus a standard SQL constructs? In case I'm doing something wrong, I want to know why – not merely do it .

Educated, but error prone,

rayc@symmetryinfo.com onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info

Ray

( Just use ) ( parentheses! ) ( ( ( lots ) ) ( of them ) ) !!!! ( ! )

( ( (

- (/)ystein -

PS. And a happy 4th to you! Except you got it all wrong! 17th of May is the day to celebrate!

I have the same thoughts sa all the rest here. I just want to add just a little bit more info. I have done lots of programming in "PICK", "AREV", "UNIVERSE", ect. Ok now the point…

I have found that "AREV" and "Opensight" selects are most easily used at the "simple" level. Simplify your selects. Try this for your select lists…

select 1…

SELECT my_table WITH TRANS_DATE < "6-6-2000"

then select 2…

SELECT my_table WITH MY_CODE=APPLES" "ORANGES"

the more simplistic the select, the more probable you will get what you want. I do clearly understand that it will cost a bit more time going the "2 select" method. And definately be absolutely sure you have an active select list going into the second select.

Now to the RLIST HANGS problem… I have never had that problem. And I am not sure what to tell ya on that.

Actually, April 25th is the correct date, but more importantly, regarding SQL versus AREV, the answer has to do with 4th July…

Have you ever wondered what happened to the 56 AREV programmers who signed the Declaration of Independence?

Five signers were captured by the British as traitors, for using incorrect comments in code and were tortured before they died.

Twelve had their homes ransacked and burned.

Two lost their sons serving in the Revolutionary Army; another had

two sons captured.

Nine of the 56 fought and died from wounds or hardships of the

Revolutionary War, or merely from GFEs in the LISTS file.

They signed and they pledged their lives, their fortunes, and their sacred honor. What kind of men were they?

Twenty-four were lawyers and jurists. Eleven were merchants, nine

were farmers and large plantation owners; men of means, well

educated.

But they signed the Declaration of Independence knowing full well

that the penalty would be death if they were captured. They knew that Java was something that they couldn't get their heads around.

Carter Braxton of Virginia, a wealthy planter and trader, saw his ships swept from the seas by the British Navy. He sold his home, his PC and properties to pay his debts, and died in rags.

Thomas McKeam was so hounded by the British that he was forced to move his family almost constantly. He served in the Congress without pay, and his family was kept in hiding. His bump disks were taken from him, and poverty was his reward.

Vandals or soldiers looted the properties of Dillery, Hall, Clymer,

Walton, Gwinnett, Heyward, Ruttledge, and Middleton. Not one 5.25 floppy disk saved.

At the battle of Yorktown, Thomas Nelson Jr, noted that the British

General Cornwallis had taken over the Nelson home for his headquarters. He quietly urged General George Washington to open fire. The home was destroyed, and Nelson died bankrupt.

Francis Lewis had his home and properties destroyed. The enemy jailed his wife, and she died within a few months, still trying to install Office 2000.

John Hart was driven from his wife's bedside as she was dying. Their 13 children fled for their lives. His fields and his gristmill were laid to waste. For more than a year he lived in forests and caves, returning home to find his wife dead and his children vanished. A few weeks later he died from exhaustion and a broken heart. If he had taken a 56K modem with him this could have been averted.

Norris and Livingston suffered similar fates.

Such were the stories and sacrifices of the American Revolution (AREV).

These were not wild-eyed, rabble-rousing ruffians. They were soft-spoken men of means and education. They had security, but they valued liberty more. Standing tall, straight, and unwavering, they pledged: "For the support of this declaration, with firm reliance on the protection of the divine providence, we mutually pledge to each other, our lives, our fortunes, and our sacred honor."

They gave Americans a free and independent America. The history books

never tell you a lot about what happened in the Revolutionary War.

America didn't fight just the British. Americans were British subjects at that time and Americans fought their own government! PCs ran at 33HZ in those days and hard disks were *really* hard.

Some of us take these liberties so much for granted, but we shouldn't.

So, take a few minutes while enjoying your 4th of July holiday and

silently thank these patriots. It's not much to ask for the price they

paid. Or they could have simply purchased a copy of SLIST from Sprezzatura in which case the whole exercise, and all the fireworks and flags and stuff would have been unnecessary.

Eric

Hi All

Thanks for the info. BTW, round here we celebrate 26th January which some are now calling Invasion day. Perhaps we should be celebrating July 5th since that is federation day (for us) and co-incidentally racked up 100 years this year.

The comma between the apples and oranges was just to see if you were awake (my misteak, it isn't in the code).

What I really had was just apples and no oranges. Either way the thing hangs on the second select. I do prefer the simple method as RH suggested but it isn't working.

The coded selection process works fine on a different (smaller) database (of course).

I tried combining the two criteria with brackets, and it hung too.

Note that the my_code (apples or oranges) is a calculated field which points to another table. It lists fine. Would this added layer of complexity be a problem.

And I did find a reference in the discussion to RLIST having a limit on the RESULT size (as opposed to the length of the select statement itself). I know it truncates if it gets too many records, but could it also choke completely?

Scott, LMS

Hi Ray

Given I am from a Universe/Prime Information/PICK background I can explain the diffence between the way the PICK select works vs the way the old AREV selects work.

In the absence of brackets PICK brackets strictly from left to right ie it executes the left most pairing it can make and combines that with the next criteria to make a new left pairing, which can lead to unexpected results if your second criteria is like

my_code=APPLES" "ORANGES" (which evaluates to (my_code=APPLES" or my_code=ORANGES")) because the way it goes is how I explained in my first post for what I didn't want.

ie given

a and b or c

you get

(a and b) or c

which isn't nice if you had

a=(trans_date < '6/6/2000')

b=(my_code=apples')

c=(my_code=oranges')

(old) AREV was more intuitive because it evaluated selection criteria that were against the same field eg my_code first. But this was less standard, so if you were porting code from another PICK application (not AREV) it broke.

I don't think the AREV/OINSIGHT/PICK constructs have a lot in common with standard SQL (The easiest way to find out what this looks like is to build a query in MS ACCESS and choose VIEW SQL). And you can use brackets in SQL but you can't in PICK. To confuse things, you obviously can use brackets in OINSIGHT, unfortunately that doesn't solve my problem.

I think (but I can't remember exactly) that SQL may also have a bracketing precedence eg ands get bracketed together before or's, I can't remember what happens with nots

eg

a and b or c or d and e

might get

²⁾

where a, b, c, d, e are boolean/logical constructs evaluating to true or false

personally I prefer to put the brackets in myself or do one criteria at a time, sequentially reducing the size of set from which records are selected. In PICK the main way of getting what you wanted was to do the sequential reduction method.

A nice thing about the Universe/PI open flavour was you could create and activate two different select lists at once, ie have an active list of invoices and at the same time create and process an active list of invoice line items for each invoice. I still haven't figured out if you can do that in Open Insight and it is annoying if you have more than 64K of invoice numbers, which means you can't just load the keys from the first select list into a dynamic array.

Maybe you do need a maths/logic degree to do this stuff.

Scott

Scott,

The comma between the apples and oranges was just to see if you were awake (my misteak, it isn't in the code).

Still checking to see if we're awake?

- Oystein -

Scott,

Are you sure there isn't something wrong with one of your tables? E.g: Your data table's got a GFE. The first Rlist doesn't discover it, because it uses the index. But the second Rlist for some reason needs/decides to read the rows of the data table, hits a damaged group, and hangs.

About your question about result size: I can't remember having read about a limit. (But please supply the link.) I just tried an Rlist that selected almost 35,000 rows from a table with keys of length 13. The result list filled 17 T rows in SYSLISTS. Is that comparable in size to your lists?

- Oystein -

It's not RLIST or OpenList or Reduce that chokes on return size. It's the windows control that the results return into that has the problem. If you were to print out the results, or just issue the select, there should be no problem. If there is, it's most likely a problem with the data.

The Sprezzatura Group

[/i]World leaders in all things RevSoft[/i]

hi all

thanks for your help

I got the thing to execute properly by changing the order that the RLISTS execute in. ie execute the RLIST most likely to return the least number of records first. This might seem obvious but the second criteria (now executed first) was optional, and I was executing the non optional criteria first. Most of the optional criteria would return fewer records than the standard mandatory criteria.

Changing the order of execution as a solution was hinted at in the related RLIST vs Reduce topic.

I don't think it has anything to do with returning information to windows controls as the entire list retrieved is handled in basic code and then used to update existing records on OI tables.

I suppose it is possible that when the big rlist is executed, that it picks up some dodgy data. I don't understand why when the smaller RLIST is executed against the whole file it processes ok, but when it is executed against the big rlist, it does get upset.

Scott

Hi Oystein

the link goes back to a 1996 record, I found by entering "RLIST limit" in the search on OI topics

http://www.revelation.com/WebSite/discuss.nsf/09d90959a1a106db8525652c0042cb86/739a4918548ea04a8525639d006b70a1?OpenDocument

Aaron wrote it, but it is a bit vague.

the info is not returned to a window control so thats not it. Your theory on indexes is a possibility although I am not sure I would have indexed two calculated fields pointing to the same place but returning different formats (they both work depending on the sequence of Rlist processing). As for your list, try doubling it in size and you will be getting close. I would be very happy if my client would archive their data on a regular basis like they are supposed to.

I am worried that it would take a very long time to find the dodgy records, but I have a go tomorrow (at work).

Scott.

Well, it's not vauge to me….ahem…

Basically, the list processor has a single string buffer it works with, so the input and output use the same memory space. As word or english tokens are pulled from the front, the compiled tokens are placed in the same space. Since compiled tokens are always smaller than the english tokens, there was always plenty of room.

The length of the english statement (LIST FILE WITH….) is not limited by this program (the LIST1.RUN programs and it's equivilents) but the RTP18 or RLIST basic programs.

In ARev 3.12 and OI, the meta limit was increased from somewhere around 1000 bytes to somewhere around 6000-7000 bytes. This allowed for longer and more complex sentences before a meta compilation error is generated.

The Sprezzatura Group

[/i]World leaders in all things RevSoft[/i]

Scott,

Your theory on indexes is a possibility…

My theory was there is a GFE somewhere. I believe there are several possible scenarios where processing hits on a bad row/group when query A is run before query B and not when B is run before A. I just made up one example.

- Oystein -

View this thread on the forum...