problem with multi select browse

davidvilla

davidvilla

Member
[FONT=&quot]I have a browse multi select <mybrowse> with a query <myquery> that fetches data from a temptable <temptable> and displays it on the browse <mybrowse>.[/FONT]

[FONT=&quot]I have a trigger (for F4 key) where I need to check whether any of the rows matches the condition <temptable>.<field1> = YES and call a procedure to update the record in the database. In doing so, I face with the problem that the row matching the condition is not updated. And this happens only in few cases (i couldn't actually capture the trend).
[/FONT]
[FONT=&quot]ON F4, F12 OF <mybrowse>IN FRAME <myframe>DO:[/FONT]

[FONT=&quot] IF CAN-FIND(FIRST <temptable> WHERE<temptable>.<field1> = YES) THEN[/FONT]
[FONT=&quot] /* UPDATE RECORD */[/FONT]

[FONT=&quot] APPLY "CLOSE":U TO THIS-PROCEDURE.[/FONT]
[FONT=&quot]END.[/FONT]

[FONT=&quot]The current selected row in the browse will be in the <temptable> buffer. And when the CAN-FIND is executed, will it actually look at the current <temptable> buffer or will it look into the entire temp-table records (query results)? Is this causing any problem?
[/FONT]
[FONT=&quot]
[/FONT]
 
If you, apart from the query, need a to access another record at the same time you need to use a defined buffer for that otherwise you will cause a conflict with the query.

Regards, RealHeavyDude.
 
I guessed this.
But this is not happening all the times. Only at very rare cases, this problem is coming. I cannot actually trace it!?!?!
 
my guess.

define temptable2 for temptable.
define ridbrowse as rowid.

on value-changed of <mybrowse>IN FRAME <myframe>DO:
ridbrowse = ROWID(temptable).
end.

ON F4, F12 OF <mybrowse>IN FRAME <myframe>DO:
find first temptable2 where ROWID(temptable2) = ridbrowse NO-LOCK NO-ERROR.
if available tenptable2 and temptable2.field1 = yes then
do:
updaterecords.
apply close to this procedure.
end.
return no-apply.
END.
 
Is the problem really due to the referencing with the same buffer name? Because, I am not actually able to reproduce the issue again and I need to give a trusty fix for it not to happen again :)
 
IMHO and please don't get mad at me, BUT:

Most developers I know don't really think about nor are they aware of what they really do when they access a database record which is in reality the default record buffer associated with the database table. The same is true for a temp-table. And it's like with the Highlander - there can only be one - record in a record buffer at the same time because the record buffer is the means to access the contents of the database record. So if you mix and match queries and for each loops with find statements - at the end of the day - you will screw up the query position or for each loop.

Plus, most developers don't really care about the scope, be they weak or strong, of these buffers too. Therefore, IMHO of course, it's always good practice to work with defined buffers and strong scoping instead of just using the inherited default buffer of a database table or temp-table, especially when you update the buffer.

Most probably you will wind up experiencing behavior that may seem funky to you if you don't pay attention to these topics.

But, I have to admit, the 4GL may seduce you into getting the impression that you don't need to think about such things :cool:
 
You must log in or register to reply here.
Back
Top