i've just rembered one "cool" thing
Code:.whatever /* it'll be compiled without any problem */
forget about it
. = comment (/* */) for readers who don't know.
However, the above example will not run without problems (or any code, even a blank procedure), if you run with zqilv client parameter, and no database connected.
I found that out last night when testing my 'RunTime Query Analyser'.
No, comments and period are not the same although I agree they're alike.
however, I couldn't understand what you meant. I ran session with zqilv and got the same result as without it. Could you explain it more detailed?
Could you provide me with a clue about 'RunTime Query Analyser'? I couldn't find it among 'Lee's links'.
What is the difference in this case? Really, I don't know. My understanding is that . is undocumented comment shorthand.
/* Only the last alert box will be shown and it's okay */
.MESSAGE
VIEW-AS ALERT-BOX INFO BUTTONS OK.
MESSAGE 1
VIEW-AS ALERT-BOX INFO BUTTONS OK.
/* ERROR */
.{include.i}
MESSAGE 1
VIEW-AS ALERT-BOX INFO BUTTONS OK.
/* ERROR */
.1 + 1
MESSAGE 1
VIEW-AS ALERT-BOX INFO BUTTONS OK.
Strictly alpha status, intended to display Index usage (a la XREF) for run time queries (ie. no need to paste the code and XREF it, you monitor the queries while the Application is running), useful for identifying bottlenecks (eg. WHOLE-INDEX) without having to mess about with the code initially. You can probably do all this in OE10 be default, but I'm on 9.
It's only a little utility, nothing special - probably noone else will be interested in it, but as I haven't had time to finish it yet, I haven't linked to it.
However, I have also found that it seems to report queries and indexes which I can't relate to searches in my application, which renders it pretty much useless anyway.
I also thought this, and indeed the application did show less anomolies when run direct from icon.
However, there were still indexes being thrown up which don't seem to make any sense, and even indexes which don't seem to exist at all (there is no corresponding record in the _index table in the database to which I am connected), but I'll report back at some point later when I have the issue nailed down into a proveable case.
The problem with the Appbuilder/compiler/whatever performing queries is fine - but shouldn't I be able to look up the index info somewhere once I have the index num?
However, this may all be misleading - I haven't tested it enough yet to confirm the problem is not with my code, and I still have faith enough in Progress to know a bug in my code is much more likely.
I've told you before there're default indexes in the database. e.g. you can create table without an index at all. As progress can't query the table without indexes it uses this default one. I think VST _index doesn't keep information about the default indexes. Maybe these indexes affects your statistics.
However, there were still indexes being thrown up which don't seem to make any sense, and even indexes which don't seem to exist at all (there is no corresponding record in the _index table in the database to which I am connected), but I'll report back at some point later when I have the issue nailed down into a proveable case.
I still have faith enough in Progress to know a bug in my code is much more likely.
I think VST _index doesn't keep information about the default indexes. Maybe these indexes affects your statistics.
it seems to report queries and indexes which I can't relate to searches in my application, which renders it pretty much useless anyway. ... the mysterious chaff that appears in zqilv output is causing me problems, because some of the queries it is reporting, have nothing to do with my app that I am aware of, though there may be some temp-table/rowObj reporting going on also.
ASSIGN
Element[1] = "16"
Element[2] = "17"
Element[3] = "18".
REPEAT loopCT = 1 TO 3:
BuiltString1 = BuiltString1 + MIN(" OR ", BuiltString1) + " nValue = " + Element[loopCT].
BuiltString2 = BuiltString2 + MIN(" OR ", BuiltString2) + " pValue = " + Element[loopCT].
END.
DISPLAY BuiltString1 FORMAT "x(75)" SKIP BuiltString2 FORMAT "x(75)".
I found one today that made me to a WTF to. You guys might get a nice chuckle out of.
Ok, here is the deal...(And you should be able to paste this directly into a procedure editor to test it) The MIN function fails to work as anticipated with certain values. I compare the literal string " OR " to the value of BuiltString. BuiltString should only be less the first time through the loop, because its value will be blank. But this fails if the literal inside the variable begins with the letter 'n', but works if the letter is 'p' (as shown in the example). (and really, it will fail with anything beginning with a-n and work with anything p-z). But this should have nothing to do with the actual MINIMUM value. Obviously, the variable value is always greater (after the first loop). This all seems to go away if I remove the SPACE before the 'n' (change it to "nValue = " instead of " nValue = "). And for my purposes, that's fine. But...I wasted an hour this morning trying to figure out if there was something menally wrong with me before I realized..AHHHHH it's a ???PHP:ASSIGN Element[1] = "16" Element[2] = "17" Element[3] = "18". REPEAT loopCT = 1 TO 3: BuiltString1 = BuiltString1 + MIN(" OR ", BuiltString1) + " nValue = " + Element[loopCT]. BuiltString2 = BuiltString2 + MIN(" OR ", BuiltString2) + " pValue = " + Element[loopCT]. END. DISPLAY BuiltString1 FORMAT "x(75)" SKIP BuiltString2 FORMAT "x(75)".
BUG OR FEATURE????
LOL!
DEF VAR element AS CHARACTER EXTENT 3 NO-UNDO.
DEF VAR builtstring1 AS CHARACTER NO-UNDO.
DEF VAR builtstring2 AS CHARACTER NO-UNDO.
DEF VAR loopCT AS INTEGER NO-UNDO.
ASSIGN
Element[1] = "16"
Element[2] = "17"
Element[3] = "18".
REPEAT loopCT = 1 TO 3:
BuiltString1 = BuiltString1 + MIN(" OR ", BuiltString1) + " nValue = " + Element[loopCT].
BuiltString2 = BuiltString2 + MIN(" OR ", BuiltString2) + " pValue = " + Element[loopCT].
MESSAGE BuiltString1 SKIP BuiltString2
VIEW-AS ALERT-BOX INFO BUTTONS OK.
END.
DEFINE VARIABLE Element AS CHARACTER EXTENT 3 NO-UNDO.
DEFINE VARIABLE BuiltString1 AS CHARACTER NO-UNDO.
DEFINE VARIABLE BuiltString2 AS CHARACTER NO-UNDO.
DEFINE VARIABLE loopCT AS INTEGER NO-UNDO.
Without the Space before the nValue & pValue it works as you would expect. BUT...with the space before the two values it does NOT return the minimum value correctly for the nValue but does for the pValue. If you run the code you will see the difference.