Re: Ranking results

LOL

OK, I will try to explicate.

Yes, to say not to use an LF is perhaps not clear - still, it seems that people don't think of the implementation of a VIEW as being an LF - you and I know that, but most don't think of the lower-level stuff. Nonetheless, I agree for clarity.

An INDEX is also an LF and will never be allowed in the table list of a SELECT statement - or as a table in any statement that I know of - is that right?

I like the object-based structure, of course - so that SQL INDEX and SQL VIEW extend the basic *FILE object with additional properties. This was just a side comment, I think - it was going through my head - I'm hungry!!

My point about pre-6.1 is that at 6.1 there was a replacement for s/o files - as I understand it. Namely, you can create an SQL INDEX with a WHERE clause in it - I think some call it a sparse index. This serves the same function of selectivity that s/o LFs do but are usable in SQE. Or will be. I've not had reason to work much in 6.1 yet so am saying only what I think I've heard!

Before 6.1 it was possible to have CQE take advantage of the selectivity of an s/o LF, that's what I was probably referring too. SQE won't even touch it.

Later - time to go get some lunch.

Vern

CRPence wrote:

Since every SQL VIEW is a logical file, IMO it is best to attempt to be more clear by suggesting either to not use a DDS logical file [there is support for program described LF so even saying DDS LF is not entirely accurate], or that *if* using a LF then use only an SQL VIEW in a FROM clause. IIRC specifying an SQL INDEX logical file on the FROM clause gives an error; i.e. an SQL INDEX is explicitly prevented versus being allowed yet forced down CQE path as with DDS [keyed] LF.

As for specifying an LF [presumably it was meant] in the FROM clause on pre-6.1, not sure what was meant to be implied. Using a S/O LF on the FROM clause of a query would honor the Select\Omit values, so what is on the WHERE clause is no different than for a query over a VIEW with a WHERE clause. The logic specified on the query need not match and could even conflict with the WHERE clause on the VIEW [obviously mutually exclusive logic would generate an empty set], but the logic specified on the WHERE clause of the query should probably just further refine the search within the set defined by the VIEW on the FROM clause. That should be the same on all releases, and the CQE would implement the query when the non-"SQL VIEW" logical file is specified on the FROM clause.

Regards, Chuck

Vern Hamberg wrote:

One should almost never use a logical file in a query - SQL has
always ignored it and had to go back to the PF, then figure out
which index (LF) to use, by its own wisdom.

SQE will never be used if you specify a logical file. The only
time - before 6.1 - to use a logical is if it were a select/omit
that matched your WHERE clause, maybe. In 6.1 there are better
alternatives - like a sparse index - I think that's the term.