Simple compare condition fails [Solved: Bug 4619731]

Question

Edit: I have found the root of the problem, and Simple compare condition fails [Solved: Bug 4619731]. I have opened a Service Request 7045745.993 on the problem.
Original text:
I have encountered the most bizarre bug today. An associate is trying to debug a 1900 line package that was NOT terminating a loop properly.
The package has the code:
    Exit when x <> y;where x and y are VARCHAR2(8) variables.
The problem is that even though the values were UNequal, the loop never ended. We added dbms_output debugging code to display x and y, and we could easily see that their values were NOT equal.
For instance, one was 19824E1A and the other was 19824E2A. Or one was 19824E1A while the other was 99999999.
I even added a block of code re-testing the condition like this:
  If x <> y then
    dbms_output.put_line(x||'<>'||y);
  Else
    dbms_output.put_line(x||'='||y);
  End if;But no matter what the values of x and y, it always reported them equal.
I found two workarounds:
1. concatenate a character (I used a period) to the end of each variable in the condition.
    Exit when x||'.' <> y||'.'2. Or, add an anonymous block before or after the Exit when..., such as:
Declare
  v varchar2(2);
Begin
  v := 'AB';
End;Curiously, when I replaced the v := 'AB'; with NULL;, the bug came back.
This bug occurs on Oracle Database 10g Enterprise Edition Release 10.2.0.3.0
I am not sure where to start to try to solve or report this problem. It pretty much destabilizes the entire PL/SQL programming foundation for all our packages. It leaves me wondering where else the code may be failing.
Has anyone seen something like this reported before?
Edited by: Steve Cosner on Aug 27, 2008 10:05 PM

Answer 1

No offense taken, SY. I was just trying to express how aware I am of the issue of comparing null values in condition statements.
All I can do here is underscore that it is not an issue with null values. The problem is with the statement in the first line. To prove that it was not null values, I coded the second line following the first:
    exit when x <> y;
    dbms_output.put_line('x='||x ||' and y='||y);The output from the run showed in the first pass through the loop, x and y were equal and were not null. So the process ran correctly that time. But in subsequent passes through the loop, they were NOT equal and were not null, but the debugging code was executed.
There is no way the values were null.
I certainly wondered about the null issue when I concatenated a character to the variables in the conditional test. But my debugging lines first confirmed that they were not null. I suspect more that the bug has something to do with the size of the package and the variables being exactly eight characters, which is 64 bits, which has special significance in many computer languages.
Regarding your concern of the variable names and scope issues, the actual variable names in the actual code can be seen below (I just used x and y for simplicity within this thread):
    LOOP
      EXIT WHEN V_LAST_PERIOD <>
          SIPK0003.COURSE_ADJUST_REC.ACAD_REC_PERIODwhile the silly anonymous block that caused the process to work, using the variable named v, was the actual code. There is no way we use simple one-character variable names in a 1900 line package. There is no way the scope of variable V extended outside the embedded anonymous block. My point was that somehow, changing the size of the compiled package object, or at least the size of the code generated for the loop process caused the package to run correctly. In fact, thinking about the
Declare V... Begin Null; End; sequence, I'll bet the PL/SQL compiler is sharp enough to notice that it was a do-nothing block, so never included it in the compiled object. As soon as I assigned V a value, the code WAS included, so the size of the generated code for the loop changed, and somehow, that caused it to run correctly.
Regarding the use of the package.record.column value above, we even copied the value to a local variable, and then used the local variable in the Exit When statement. Doing that made no difference.