Is it a Bug or a feature?
- Thread starter karthik
- Start date
Lee Curzon
Member
. = 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'.
Lee Curzon
Member
As you haven't clarified what offended you, I don't know what I'm supposed to forget, but I will attempt to do so nonetheless.
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'.
Lee Curzon
Member
What is the difference in this case? Really, I don't know. My understanding is that . is undocumented comment shorthand.
I ran an empty procedure last night in the Appbuilder with zqilv and no database attached. Lot's of errors. (This was after I had been running in the same session with a database attached).
Incidentally 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.
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.
Hmm, I played with that ages ago and I've already forgotten all problems.
First of all, a period subdues all code to the next period. It differs from the standard comments, doesn't it?
But nevertheless I could find out some problems
Code:
/* 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.but the following snippets are wrong.
Code:
/* ERROR */
.{include.i}
MESSAGE 1
VIEW-AS ALERT-BOX INFO BUTTONS OK.
Code:
/* ERROR */
.1 + 1
MESSAGE 1
VIEW-AS ALERT-BOX INFO BUTTONS OK.I've never liked zqil because it 'spoils' database log. am I right your tool analyses it to get runtime statistics?
Lee Curzon
Member
Yes, but I would only ever use zqil on development db anyway, because as you say it fills the log very quickly with garbage.
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.
When I first looked at it, I assumed the queries reported would just relate to the working database, but I haven't yet been able to work out where the 'extra' information is coming from - I was thinking of raising at as a question on Peg or with Tech Support if I can't make further headway.
It may be I'm missing something obvious, or (heaven forbid) there is a bug in my code. I've considered temp-db, hidden files, but it doesn't seem related - which is why I haven't pursued the util heavily at the mo.
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.
When I first looked at it, I assumed the queries reported would just relate to the working database, but I haven't yet been able to work out where the 'extra' information is coming from - I was thinking of raising at as a question on Peg or with Tech Support if I can't make further headway.
It may be I'm missing something obvious, or (heaven forbid) there is a bug in my code. I've considered temp-db, hidden files, but it doesn't seem related - which is why I haven't pursued the util heavily at the mo.
I reckon it might be the compiler's queries. You know compiler queries a lot during compilation and maybe these queries are a reason of your problem.
Lee Curzon
Member
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.
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.
Lee Curzon
Member
An excellent point - I hadn't considered them, as I didn't realise default indexes weren't recorded in _index.
Should be easy to test anyway...
Lee Curzon
Member
Run-Time Query Analyser update:
There was a bug in my code, but this only counted for about 5% of the problem.
Good try, but Default Index info is recorded.
Yes, it is temp table stuff, introduced as an 'enhancement' in 9.1D06. I am on 9.1D07.
http://www.peg.com/lists/peg/history/200308/msg00327.html
However, after much brainstorming, I found a clever (IMNSHO) workaround.
Hopefully, if it holds up ok, I'll post the util in the next couple of weeks for anyone who is interested.
There was a bug in my code, but this only counted for about 5% of the problem.
Good try, but Default Index info is recorded.
Yes, it is temp table stuff, introduced as an 'enhancement' in 9.1D06. I am on 9.1D07.
http://www.peg.com/lists/peg/history/200308/msg00327.html
However, after much brainstorming, I found a clever (IMNSHO) workaround.
Hopefully, if it holds up ok, I'll post the util in the next couple of weeks for anyone who is interested.
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 ???
BUG OR FEATURE????
LOL!
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!
Unless I am missing something I think you are mistaken as otherwise it is a remarkable conincidence that it failes for a-n and works for p-z and the string you are comparing with begins " O" that happens to be right in the middle of a-n and p-z in the alphabet. The comparison is alphabetic and not case sensitive so anything beginning " n" is less than anything beginning " o" and anything beginning " o" is less than anything beginning " p" and " " is less than any letter of the alphabet. I think the min function is working as you would expect.
KnutHandsome
Member
Code:
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.Rewritten slightly to include definitions and show string building.
Maybe I'm missing your point, but the MINIMUM function will work like any normal >, <, = string comparison, and since 'n' < 'o' and 'p' > 'o'...
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.
Here I forgot the declaration for the top...not that it isn't easy to type out.
Here I forgot the declaration for the top...not that it isn't easy to type out.
PHP:
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."Maybe I'm missing your point, but the MINIMUM function will work like any normal >, <, = string comparison, and since 'n' < 'o' and 'p' > 'o'..." as KnutHandsome stated just prior to your last post.
" OR" < " nV" = FALSE
As the first character in each string is a space, the second character is then compared: 'o' > 'n' so MIN(" OR ", " nValue") returns " nValue".
Removing the space before the nValue causes a string comparison thus:
" OR" < "nV" = TRUE
Now when comparing the first characters, ' ' < 'n' so MIN(" OR ", "nValue") returns " OR ".
Simple, no?
