Thanks for the replies... In this example I was using, the ID was not on file, so it would not have taken the LOCKED clause. I just added the locked clause to my actual failing code to test the theory and it still takes the ELSE clause because the record is truly not on file.
I tried George's idea of using named common and the problem still happens. One last clarification, the problem seems to occur if the READ statement is a READU. If the statement is a regular READ, it does not happen. -Troy -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of David Jordan Sent: Tuesday, December 22, 2009 1:23 PM To: U2 Users List Subject: Re: [U2] [UV] odd problem with read statement assigning variablewith random data with else clause in pick flavor Hi Troy The problem with that code is that the else clause is taken when the record is locked. You are assuming if the else clause is taken that the record does not exist, which is not a safe assumption. I would suggest Readu citem from fv, key locked * locked options End then * then options End else Citem = "" end -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Buss, Troy (Logitek Systems) Sent: Wednesday, 23 December 2009 7:59 AM To: [email protected] Subject: [U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor We are running universe 10.2.10 in pick flavor. I have a program (part of a 4gl subroutine) that simplified does the following: CITEM = "" READU CITEM FROM F.FILE, CID THEN END ELSE IF CITEM # "" THEN PRINT "CITEM IS NOT NULL!" END According to the documentation, when running in pick flavor, the value of CITEM is unchanged if the read fails. What happens is that CITEM is sometimes assigned to a random value and not NULL. Right now it is being assigned to zero. Last week, this same CITEM was being assigned to an escape sequence (about 8 characters long) when the read failed. CITEM is a non-named common variable. This issues does NOT happen if CITEM is not a common variable. The result also has varied if I use READU vs READ. Clearly there is a bug here in retaining the value of CITEM with a READ statement in pick flavor. Unfortunately, I have not been able to create a simple example to reproduce this problem outside of the 4gl. And this does not happen in all the code, only in one section so far and IS reproducible in this one case from logon session to logon session. Any ideas? -Troy _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
