I've looked up the discussion items on the FS445 "IDX_SETS Function 4 returned error code -30720" error. It all seems a bit inconclusive - so I'm asking the question anew.

Our user : Win 95 on wkstns. ARev 3.12. NPP 1.5. NT Server. Revelation NT Service.

Recent changes : Sort file location moved from server to local hard disk due sharing violation crashes during selecting. Data file growing.

Problem : Selects in several reports from a file of about 12,000 records worked fine until now. When select does …WITH FIELDA EQ "VALA" AND WITH VALB EQ "VALB" (both fields Btreed) we get the error.

If we do it successively, it works fine - unless …

…WITH FIELDC EQ "VALC" AND WITH FIELDA EQ "VAL A" ; … WITH FIELDB EQ "VALB" (FIELDC unindexed) it crashes

but …

…WITH FIELDA EQ "VAL A" ; … WITH FIELDB EQ "VALB" AND WITH FIELDC EQ "VALC" works OK

Presumably the coding of IDX_SETS will indicate to an insider what Function 4 does and in what circumstances error -30720 occurs - as a clue to what could be happening and therefore how to fix or avoid it.

Splitting selects into bits is not an acceptable answer to something which normally works OK - as so it should.

Help please …

Hi Richard

]Splitting selects into bits is not an acceptable answer to something which normally works OK - as so it should.

I don't worry too much about what should and should not work. (Do a search on "REDUCE" AND "RLIST" to see my worrying about what *does* work). I deal with unexpected results by rearranging code until it works.

I haven't had your specific error but I have had a lot of trouble with RLIST and Reduce on complicated selection clauses. If I coded the whole select statement together I got different results each time I ran it from the same unchanged data. The straw that broke my select's back was a complicated symbolic field in the dictionary that looked up another table using a date entered as a parameter by the user, and then stored in common (I think it was stored in common). I think the real problem was that the select itself may have been too long, or returned more records than it could handle (a multi table many records-]more records exponential effect).

The other thing the select used to get stuffed was something like

SELECT THINGY_TABLE WITH THINGY_ATTRIB1=THIS" "THAT" AND WITH THINGY_ATTRIB2=RED" "ORANGE"

which got bracketed up strictly left to right so the result was

((((SELECT THINGY_TABLE WITH THINGY_ATTRIB1=THIS")

OR WITH THINGY_ATTRIB1=THAT")

AND WITH THINGY_ATTRIB2=RED")

OR WITH THINGY_ATTRIB2= "ORANGE")

Ie you would get everything orange no matter what thingy_attrib1 was. I found this was different to how AREV bracketted things up.

So I split long selects up, putting stuff that cuts the list down as much as possible first and the criteria including complicated symbolics last. Ie I'd execute several RLIST commands one after the other checking in between that records had actually been selected before continuing. I'd especially split up the selects like the one above to stop the bracketing problem. I avoid using the REDUCE command because I never managed to get the results I expected when using it.

Good luck, but I think you may have to change your code.

Scott, LMS

You touch on an old problem which I raised with RTI years ago.

If you write :-

WITH FRUIT EQ "APPLES" "PEARS" AND WITH SAUCE EQ "CUSTARD" "CREAM"

the full syntax used it :-

WITH FRUIT EQ "APPLES" OR WITH FRUIT EQ "PEARS" AND WITH SAUCE EQ "CUSTARD" OR WITH SAUCE EQ "CREAM"

As ANDs take precedence over ORs - disaster!

With the abbreviated syntax the user naturally imagines the implied ORs will take precedence - but that's not what happens.

I think that RTI should recognise (have recognised) this problem and made their products behave as normal users would expect, processing abbreviated syntax first before applying Boole's rules.

I think I've educated most of our users in Boole's rules and to sprinkle brackets around liberally. In our T-List report writer I've made the system detect this abbreviated syntax and put in the brackets before letting the Arev or OI select processor loose on it.

The second point is that our T-List allows (the braver) users to write their own selects. One cannot expect them to go through the contortions you describe! The syntax should (and usually does) work - except for the IDX_SETS problem and also previously a sharing violation whrn the sort files were on the server. These both appear to be memory-related problems and may be specific to ARev on Win 95.

Lastly, I have never come across the same select working differently on the same data on successive runs. However, I have had certain complex selects working differently depending whether certain fields were Btree-indexed or unindexed. On pondering how the two processes had to be processed the reasons became apparent - although not in any way reassuring! The only sure answer is to test selections very carefully - it is easy enough to get the basic select sentence wrong, quite apart from not fully appreciating how it will be interpreted and processed.

Firstly, apologies - I've just realised I've put an Arev-specific query under OI-specific.

For the lack of any constructive response as to what causes this problem and how to fix …

RTI - are you somewhere out there????

Can you please at least tell me from your source code what circumstances cause the error condition to occur and the message "IDX_SETS FS445 error function 4 error code 30720" to be called? Perhaps we can then get a clue or two.

If the answer's too embarrassing for public display, just email me at [email protected] marked "Confidential"!!!

With my usual faith in RTI, I've told my client that we'll have a fix for him in no time at all and that he won't have to keep experimenting with splitting up his SELECTs into little bits until it works.

Thanks.

Richard-

IDX_SETS is an assembly language program used for sorting and resolving Index lookups.

It's errors almost always revolve around memory settings.

Given that you've probably already checked these:

Is expanded memory set for Arev?

Does config.sys have files=200, buffers=30

Is write-behind caching disabled for the nmachines?

Is it every machine, or just some?

Do the machines have plenty of free space?

I'll start digging into the code and see what we can find.

Mike

Mike

Many thanks for quick response. I'll ask my client to check the memory settings/figures on the PC giving the trouble first. Easy enough to ask him to do WHO and report back.

I got the impression that the trouble was bound up with memory but it would be helpful indeed to be able to get near the cause from the error message before taking a blunt instrument to the problem. I also wondered if it might be Win95-specific or Win95-prone.

Also it's the same people who had a similar SELECT problem solved by moving temp sort file location from server to local PC. Thankfully none of our other users eeem to have met these sorts of problems.

Richard

View this thread on the forum...