Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

At 04 SEP 2003 02:43:02PM Gerald Lovel wrote:

In the AREV days, a select list could be refined by issuing a subsequent select, which would work from the active list.

The documentation for REDUCE says that mode=2 refines the select criteria, joining the new criteria to a cursor's criteria with AND. This would be similar to the AREV multiple select sequence.

Well, when I try this the previous criteria of the cursor are not preserved, and new criteria result in a new select, not a refined list. Does anyone get a different result?

Gerald


At 04 SEP 2003 03:38PM Richard Hunt wrote:

Gerald,

I have tested the REDUCE statement for you using the following paragraph…

DECLARE SUBROUTINE REDUCE

STRING1=WITH {PERIOD} EQ "1994*11"'

STRING2=WITH {COR_DATE} EQ ""'

CURSOR='

FLAG='

REDUCE(STRING1,"",1,'SA',CURSOR,FLAG)

REDUCE(STRING2,"",2,'SA',CURSOR,FLAG)

SELECT 'SA' BY "" USING CURSOR ELSE

END

IDS='

DONE=0

LOOP

READNEXT ID USING CURSOR BY AT ELSE

DONE=1

END

UNTIL DONE DO

IDS=ID

REPEAT

The reduction worked perfectly for me. This table has a total of 1,234 rows. 16 of the rows have the period of "1994*11". Of the 16 rows, 10 of them were corrected. Given the final result was 10 rows selected, the reduction did procss correctly.

Hope this helps at least a little.


At 04 SEP 2003 05:44PM Gerald Lovel wrote:

Richard,

I just knew someone would tell me this. What you are saying is, when REDUCE is called twice within the same routine, and mode=2 on the second call to refine the reduction, REDUCE will correctly return the intersection set from the 2 criteria sets. You know, I believe this.

Here is what I was trying to do. I replaced QBF. (What? containing brackets do not work?) Then I thought, why not allow for refining queries, which never worked in AREV? Let the user provide additional criteria after looking at the query results, and append the new clauses to the reduction by calling REDUCE with mode=2. You know, this doesn't work. I suspect that since the "WITH" clauses of the reduce command are not stored in @CURSORS, there is no way for reduce to append the criteria.

I also think that the logic within reduce does not work like AREV's RList SELECT, where successive selects produce refinements. I'm guessing that RList SELECT starts off by checking @List.Active. If a list is not present, it selects the specified table. From then on, SELECT readnexts through either the previous select list or the table, thus producing cursor refinement.

I sort of hoped that REDUCE would do the same thing; that it would work from the existing cursor to apply the additional criteria. But fixing these things is what keeps us programmers employed, yes?

Gerald


At 04 SEP 2003 06:34PM Richard Hunt wrote:

Gerald,

Well all I can say is that I am disappointed with the "SELECT", "REDUCE", "RLIST", and indexing capabilities of OI. They just seem to be inconsistant and unreliable. Definately hazardous when migrating from other applications.

And well since they have been doing what they do for a very long time (for what??? 10 years or so), they can not be corrected or changed.

I considered this seriously around the first of this year and I decided to create my own functions. Now I have no headaches and I can even fix the bugs because I have the source code to fix it.

Some might consider this reinventing the wheel… and I agree! And it was necessary!


At 04 SEP 2003 07:29PM Gerald Lovel wrote:

Richard,

Mea Culpa. I found a bug in my code, after which the REDUCE mode=2 worked. In fact, it seems to work just like RList SELECT, in that sort order is preserved. Since REDUCE is not actually storing the with clauses, I believe that mode=2 is using the existing cursor for the reduce instead of the whole file. My mistake.

As far as reinventing the wheel, I actually find myself improving on what went before in AREV. For example, now my query function allows users to refine queries interactively, which AREV could not do. Maybe this is a good thing, and maybe some of this re-inventiveness should work its way into the product.

Gerald


At 07 SEP 2003 12:39AM Bob Silverstein wrote:

I tried the select/reduce functions in OI32 and found them not worth the bother to learn. I am sticking btree.extract. I wonder if the problems you are having are related to whether or not your columns are indexed. As you probably know, adding another btree index is easy enough so why not use btree.extract?

Good luck.


At 07 SEP 2003 04:12AM Peter Lynch wrote:

"I actually find myself improving on what went before in AREV."

Thats what OI is.


At 08 SEP 2003 09:31AM Gerald Lovel wrote:

Peter,

I appreciate your vote of confidence in OI, especially as other of your postings reflect your frustration with OI tools.

I have spent 6 months on my AREV to OI conversion, and I am half-way through getting basic utilities and features working. List or Cursor based program editing? No way. Global dictionary search and edit? No way. Working query windows? No way. Simplified RList reporting? No way. Inheritance-based object programming? No way.

Well, we really do need a "BETTER THAN AREV" product. In fact, that is what I am working on.

Gerald

glovel@wares.cc


At 08 SEP 2003 10:21AM Peter Lynch wrote:

May i join your club.

I have a loyalty to the product because i have a loyalty to the people who i convinced that arev was an appropriate course to follow.

I went to extremes to push arev. I once was running a course which i called "Advanced Programming", and along came a couple of 'students' from a major payroll company here. This course was the birth of a payroll system which was used by a significant percentage of the workforce.

I pushed it to the aerospace industry - configuration management which apparently still lives in arev.

etc etc.

I know that the windows version of arev should have taken on the philosophy of arev, and would have been a very successful product.

You apparently know that too. I know a couple of others who know it too.

The message is not getting across to the people who matter.

Since they are not interested in doing it, would it be possible to find a sound basis to enable the real windows arev to be written by an outside team?

Writing a full replacement is a big task - well nigh impossible.

There is nothing still which is as consistent as arev.

Solutions like sweb are a pointer to the way to go.


At 08 SEP 2003 11:11AM The Sprezzatura Group wrote:

Well don't spend too much time on this stuff…

List or Cursor based program editing?

should make OI 7 or soon thereafter

Global dictionary search and edit?

Released as freeware on this discussion board by Sig and others a couple of years back.

Working query windows?

Whilst the syntax changed for OI (all operators inc at beginning etc) it supports most things AREV did with the notable absence of a READ event being fired. If this is important for the cost of a day or two of programming you could have used our S/QBF.

Simplified RList reporting?

S/List and/or the improved ORMAIN in OI 7.

Inheritance-based object programming?

New more rigorous model in OI 7 allowing third parties to extend the IDE etc.

Of course you CAN do it all yourself but it seems strange to do so. Y'see the new management actually USE the toolset themselves so it's in their interest to create a usable toolset. Contrast this situation to a couple of years ago where the main programmers building OI had their own UI for editing etc so didn't come up against the restrictions themselves.

FWIW

The Sprezzatura Group

World Leaders in all things RevSoft

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/f6d01e9ac7b3935c85256d970066d13e.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1