Any Idea what's Wrong with my Query?

[dayv2005]

Error Message (3326)
"Buffer Task is in conflict with previous use of the Query br-Task

DO WITH FRAME {&FRAME-NAME}:
   CLOSE QUERY br-Task.

   IF cb-Programmer:SCREEN-VALUE = "ALL" THEN
       OPEN QUERY br-Task FOR EACH Task WHERE Task.StatusFlag = "N" NO-LOCK,
       EACH Programmers WHERE Programmers.ProgrammerID = Task.MISID.


                    
   ELSE 
       OPEN QUERY br-Task FOR EACH task WHERE task.StatusFlag = "N" NO-LOCK
            AND Task.MISID = cb-Programmer:SCREEN-VALUE NO-LOCK,
       EACH Programmers WHERE Programmers.ProgrammerID = Task.MISID.
   
                                                                                                                                                      
                                                     
END.
END PROCEDURE.

 

[dayv2005]

nvm got it

 

[Serj HAMMER]

twin NO-LOCK

Hello, dayv!

OPEN QUERY br-Task FOR EACH task WHERE task.StatusFlag = "N" NO-LOCK
AND Task.MISID = cb-Programmer:SCREEN-VALUE NO-LOCK,

- NO-LOCK should not be plased between AND.
And it can be used only once per each table.
I think, that after Programmers table You could place NO-LOCK too.

 

[lord_icon]

Re: twin NO-LOCK

I don't like that style. Harder for debugging / error trapping / reading.
I would use

FOR EACH tableName do the lock here, informs progress immediately required lock before have to then process the matching criteria, the record is therefore in the correct buffer.

Syntax
FOR EACH tableName withYourLock
WHERE required row attributes
JOIN ifRequired here.

Also VERY BAD / Dirty technique to use = Widget:SCREEN-VALUE. Use a variable. On initialization of the query assign a var the Widget:SCREEN-VALUE. For future + backward compatability. By using the widgetName development is not free to be realized. Think other folk may be required to use your code later and not knowing widgetNames makes life harder, compared to a simple iProgrammer. Have a key in remarks within the src eg
/* 1 = Jim Bob 2 = Dude 3 = Dave */
Good luck
Regards

 

[joey.jeremiah]

Re: twin NO-LOCK

I don't like that style. Harder for debugging / error trapping / reading.
I would use

FOR EACH tableName do the lock here, informs progress immediately required lock before have to then process the matching criteria, the record is therefore in the correct buffer.

informs progress immediately required lock before have to then process the matching criteria ???!

the statement is parsed and compiled as a whole. you're saying the query first reads the records locked and then not, what are you trying to say ???

there are no issues what so ever putting the lock anywhere in the record phrase for every buffer, it's a matter of organization.

Syntax
FOR EACH tableName withYourLock
WHERE required row attributes
JOIN ifRequired here.

Also VERY BAD / Dirty technique to use = Widget:SCREEN-VALUE. Use a variable. On initialization of the query assign a var the Widget:SCREEN-VALUE. For future + backward compatability. By using the widgetName development is not free to be realized. Think other folk may be required to use your code later and not knowing widgetNames makes life harder, compared to a simple iProgrammer. Have a key in remarks within the src eg
/* 1 = Jim Bob 2 = Dude 3 = Dave */
Good luck
Regards

it's perfectly acceptable and makes for good practice to use widgets, instead of defining and setting hundreds of needless variables.

it makes for simple, elegant procedures.

 

[KnutHandsome]

Apart from the normal Icon technical scoops, I just read him as saying FOR EACH <table> NO-LOCK is easy to grep, and splitting GUI from DB access is a good idea.

 

[joey.jeremiah]

I don't like that style. Harder for debugging / error trapping / reading.
I would use

FOR EACH tableName do the lock here, informs progress immediately required lock before have to then process the matching criteria, the record is therefore in the correct buffer.

Syntax
FOR EACH tableName withYourLock
WHERE required row attributes
JOIN ifRequired here.

Also VERY BAD / Dirty technique to use = Widget:SCREEN-VALUE. Use a variable. On initialization of the query assign a var the Widget:SCREEN-VALUE. For future + backward compatability. By using the widgetName development is not free to be realized. Think other folk may be required to use your code later and not knowing widgetNames makes life harder, compared to a simple iProgrammer. Have a key in remarks within the src eg
/* 1 = Jim Bob 2 = Dude 3 = Dave */
Good luck
Regards

... and where does it say any of that ?

 

[joey.jeremiah]

in regards to splitting bl/ui, i don't understand how using a variable instead of input-value/screen-value is relevant.

with a distributed application the client would query a dataset/temp-table and could still use widgets in the where clause.

 

[lord_icon]

Thx KnutHandsome. I did NOT explain with appropriate syntax. At least somebody understood what process I were trying to achieve.
I didn't say it was wrong to use the :screen-value attib, though a rather dirty method. Just because it is possible why do it? It is possible to go and blow your dumb brains out, though I do not see you reaching for a Walter PPK.
Somebody who is an external member and not involved in the development process has to use your code. Make it easier on them. By using widget names, that widget can not be modified e.g. renamed at a later date. New widgets are limited to names, it is not very dynamic to HARD CODE widget names.
Thx 4 the support KnutHandsome, you are on the same page. Shame about other folk.

 

[joey.jeremiah]

sorry, but there are some things i just feel strong about, as you were in your original post.

you're saying you'd rather define and set needless variables instead of using widgets because why ? seems to me that would be messy.

even in your suggestion you would still need to reference widgets but you would additionally need to define and set other variables.


and that somehow defining the lock at the end of the record phrase causes inefficient query processing ?!

instead of saying it's dirty or i'm dumb i'd be happy to hear an actual argument or any point you're trying to make.

 

[TomBascom]

FWIW I was once in the "place the lock specification at the end of the record phrase" camp. But I now prefer to place the lock immediately after the table name.

I find it a bit easier to read and it seems to make multi-line formatting of long statements flow a little better :awink:

It makes no difference at all to the compiled code.

I've got no problems with handle:attribute in general and I certainly agree that littering code with specious variables isn't helpful but I do think that the SCREEN-VALUE attribute being used in a WHERE clause is a bit of a red flag. Unless, that is, the record is a temp-table record.