Dynamic Find-statement: what's wrong?

palthe

Member
Hi,

I've created a temp-table htempxmlcolumns containing 4 fields:
username, database, table, fields.

Then I do some logic and I fire this statement:

IF htempxmlcolumns:HAS-RECORDS THEN
hbufxmlcolumns:FIND-UNIQUE(SUBSTITUTE("where username = &1 and database = &2 and table = &3",QUOTER(huser:SCREEN-VALUE),QUOTER(cdata),QUOTER(ctable))).

I get the
** Unable to understand after -- "username = admin AND". (247)
** Cannot understand expression involving AND operator. (249)

When I do a

MESSAGE SUBSTITUTE("where username = &1 and database = &2 and table = &3",QUOTER(huser:SCREEN-VALUE),QUOTER(cdata),QUOTER(ctable)).

I get:

where username = "admin" and database = "exactopenedge10" and table = "admdat"

So no problem there... Can anyone explain? I tried using QUOTER on the cdata/ctable and all sorts of things.

Funny: if I lose the substitute and just do
hbufxmlcolumns:FIND-UNIQUE("where username = 'admin' and database = exactopenedge10 and table = 'admdat'").

I get the same message.
 

GregTomkins

Active Member
Suggestion: change 'table' to 'tablex', or something else that is not a reserved word. This line of code doesn't compile either:

def var table as c.
 

palthe

Member
Well Greg, that was very useful! I changed the names to databasename and tablename and things are running smoothly now. Thanks man!
I'd surely like to see a list of names NOT to be used in expressions, because they give errors on run-time. Or Progress could give me a better error...

Anyway, back to the drawing board, and kudos to you Greg :D!
 
I'd surely like to see a list of names NOT to be used in expressions, because they give errors on run-time. Or Progress could give me a better error...
I must admit, I assumed your problem was an embedded quotes issue.

Anyway, to your follow on question:

Try the undocumented -zgenkwlist to see keywords. eg (lifted from George Potemkins parameter list):

Code:
prowin32.exe -zgenkwlist > keywords.txt

Also, there are the ABL KEYWORD() and KEYWORD-ALL() functions.

Example:

Code:
FUNCTION GetKeywordsInString RETURNS CHARACTER
(INPUT cString AS CHARACTER):

    DEFINE VARIABLE i AS INTEGER    NO-UNDO.
    DEFINE VARIABLE cKeyWords AS CHARACTER  NO-UNDO.

    DO i = 1 TO NUM-ENTRIES(cString, ' '):

        IF KEYWORD-ALL(ENTRY(i, cString, ' ')) <> ? THEN
            cKeyWords = cKeyWords + ENTRY(i, cString, ' ') + ','.

    END.

    RETURN RIGHT-TRIM(cKeyWords, ',').

END.
    

MESSAGE GetKeyWordsInString('username = "admin" and database = "exactopenedge10" and table = "admdat"')
    VIEW-AS ALERT-BOX INFO BUTTONS OK.

There is also the -k 'keyword forget' startup parameter, though I assume (possibly wrongly) it doesn't work for dynamic code.
 
I don't know. I rarely use dynamic coding explicitly. It should be simple enough for someone who's not me to do a quick test.

I would assume the same rules apply as to static code.

So reserved keywords should not be used. These are the ones with ticks against them in the index (and tested using the KEYWORD function).

eg.

Code:
DEFINE VARIABLE ABSOLUTE AS CHARACTER  NO-UNDO. << ok
DEFINE VARIABLE DATABASE AS CHARACTER  NO-UNDO. << not ok
 
I would assume the same rules apply as to static code.

Code:
DEFINE VARIABLE hTable AS HANDLE     NO-UNDO.

CREATE TEMP-TABLE hTable.
hTable:ADD-NEW-FIELD('DATABASE','CHARACTER',0,?,''). 
htable:TEMP-TABLE-PREPARE('tttest'). << ok

DEF TEMP-TABLE tttest
    FIELD DATABASE AS CHARACTER << not ok
    .

Indicates my assumption was wrong.
 

tamhas

ProgressTalk.com Sponsor
The statement being dynamic has nothing to do with it. A reserved keyword is a problem in any code (as in most languages). Sometimes you can get away with it, but it is asking for trouble.

BTW, one of the advantages of some form of Hungarian notation is that constructs like tbTable or chTable are unlikely to ever conflict with a keyword, either in the current set or in any future set.
 

tamhas

ProgressTalk.com Sponsor
Yes, but it is harder to work with variables called asjfd and alkpoiwur and the like.
 

palthe

Member
The statement being dynamic has everything to do with not getting an explicit error.
You are right concerning the fact that keywords may or not may used in static and dynamic statements, but if you code statically you get a whole different error (which is a LOT more explicit in my belief).

And there is a difference between dynamic temp-tables and static temp-tables as you can see in Knut's example. Progress shouldn't accept the dynamic tt as stated by Knut in the first place...
It is not conistent if Progress let's you create a tt with a keyword as field, even let's you fill it with data and then finally does not let you query the tt.
 
Top