from PS_EARNINGS_TBL A
WHERE A.EFFDT = (SELECT MAX(A_ED.EFFDT) FROM PS_EARNINGS_TBL A_ED WHERE A.ERNCD=A_ED.ERNCD AND A_ED.EFFDTSYSDATE)
AND NOT EXISTS (SELECT ‘X’ FROM PS_EARNINGS_TBL WHERE ERNCD = A1.ERNCD AND EFFDT <= SYSDATE)
END-SELECT

Another fun point is the different behaviors of the “translate(source,from_set,to_set)” function between Oracle SQL and SQR. If the value of “from_set” is longer than the value of “to_set”, Oracle will delete any characters from “source” that are in the unmatched characters at the end of “from_set”, while SQR will just ignore them….

I guess I’ve always used functions and operators (e.g. substr() and ||) that exist in both languages. Thanks, I’ve learned something today.

For example, I made a symple SQR using contrived BEGIN-SELECTs using the expressions of the style you mentioned above, then ran it with “-s”. Here are the results:

$ sqr sql_expressions_test.sqr -s
SQR V6.2
Copyright (C) Brio Technology 1994-2001. All Worldwide Rights Reserved.

Cursor Status:

Cursor #1:
SQL = SELECT ‘x’ from dual where substr(dummy,1,2)=’50′ or dummy like
dummy || ‘%’
Compiles = 1
Executes = 1
Rows = 1

Cursor #2:
SQL = SELECT ‘y’ from dual where dummy like :1 || ‘%’
Compiles = 1
Executes = 1
Rows = 0

SQR: End of Run.

Note that the limit of SQRs parsing is to look for SQR variables (i.e. $ or # punctuation marks) and convert those individual tokens in the expression to bind variables…..

I don’t have immediate access to tables with DEPTID and SETID columns, but I think if you repeated the test usuing your original examples in that environment, you would see the same results.

I could list some other evidence of various sorts to support my claim; let me know if you would like further convincing….

WHERE SUBSTR(DEPTID, 1, 2) = ‘50′
OR DEPTID LIKE SETID || ‘%’

I would guess the substring function and concatenation are SQL expressions.

WHERE DEPTID LIKE $dept_prefix || ‘%’

I would guess that SQR evaluates “$dept_prefix || ‘%’” and sends it to the database as a bind variable.

I suspect your theory of SQR evolution is correct, and I wonder about the decision process that led to the apparent practice of freezing old commands, even in the light of new data types.

I have never seen manuals from SQR v1 days or anything, but I have always assumed that the first few versions of SQR did not support expressions at all. Instead, you had only the “simple” commands: ADD, SUBTRACT, EXTRACT, GET, PUT, etc.

Later, it became clear how much a pain it was to do anything at all complicated using only those commands, so the LET command was added to the language, and along with it support for expressions — but it was “too late” for those expressions to be allowed in the general spots that other languages would allow them (e.g. my personal “favorite”, as arguments to procedure calls)….

(It seems to me that this “theory of SQR evolution” also explains why there is such obvious duplication between the “simple” commands and the functionality available from expressions….)

Similarly, I suspect that support for arrays was added after the language was already established, and in general the support was added by creating new language features rather than by trying to retrofit support to old language features that hadn’t been designed to work with arrays originally.

The C switch and the SQR evaluate may serve different purposes, just as the C language (sometimes called a high level assembler) and the SQR language (perhaps an interpreter of a streamlined version of COBOL with enhanced output) serve different purposes. The switch command might speed up a program while the evaluate command might untangle the source code. I decided to compare them because the SQR Language Reference minimized their differences.

If it stunned you to learn that SQR won’t take an expression as the test value, brace yourself. SQR’s nouns (data objects) and verbs (commands) are far from orthogonal. Many commands take scalar values (literals and variables) but not array elements. Some commands take literals but not variables. And very few commands take expressions. I’ll have to research it, but I think expressions are only allowed in the let command.