You normally should leave the EQNULL OFF. You may effect perfomance when joining tables together if it is on. I guess normally you really shouldn't be joining tables together on a field that might be null, but if you did it whould change your results.
Troy Sosamon ===== Original Message from [EMAIL PROTECTED] at 7/23/02 10:14 pm >At 10:27 PM 7/22/2002 -0400, Thomas J Cimicato wrote: > >>What is the prevailing thought on the use of the EQNULL setting?? >>Should you code for it ON or OFF as a standard? (Off seems to be >>the default in the rbase.cfg file. ) >>When would you not want NULL to equal NULL?? > > >Thom, > >Using The Glorious R:BASE 2000 (ver 6.5++) and higher, here's how the >expressions are evaluated CORRECTLY when EQNULL is SET to ON, > >R:BASE uses special processing on simple IF commands for maximum >speed. However, the way these were processed was not consistent with >the way complex IF commands or WHILE commands were processed >with regard to comparisons using NULL values. The EQNULL setting >at TRUE means that a comparison between two NULL values is a match >and that a comparison between a NULL value and a non-NULL value is >not. When EQNULL is set to FALSE then a comparison between two >NULL values is not a match nor is a comparison between a NULL value >and a non-NULL value a mismatch. The NULL value essentially make >the whole thing "unknown'. This behavior was followed in WHILE and >complex IF commands but was not followed in simple IF commands. >A simple IF command has only one comparison and the left side is a >simple variable and the right side is either a variable or a constant. A >simple IF does not have any expressions. > >Compare these code samples: > >SET VAR v1 TEXT = NULL >SET VAR v2 TEXT = NULL > >SET EQNULL OFF >IF v1 = .v2 THEN > -- will not be a hit >ENDIF >IF v1 <> .v2 THEN > -- will not be a hit >ENDIF >IF v1 <> 'This' THEN > -- will not be a hit (it used to be before this fix) >ENDIF > >SET EQNULL ON >IF v1 = .v2 THEN > -- will be a hit >ENDIF >IF v1 <> .v2 THEN > -- will not be a hit >ENDIF >IF v1 <> 'This' THEN > -- will be a hit >ENDIF > >Before the fix in 6.5++, the comparison "IF v1 <> 'This' THEN" would >be a hit with EQNULL set ON or FALSE when it should only be a hit >when EQNULL is ON. This means that now: > >"IF (.v1) <> 'This' THEN" and "IF v1 <> 'This' THEN" > >will both process the same way. In the past they would be different >because of this problem. > >In your code if you want the comparison of a NULL variable and a >non-NULL constant to be a hit then you should run with EQNULL >set ON. > >Hope that helps you understand the CORRECT use of EQNULL. > >Enjoy, > >Very Best Regards, > >Razzak. > > >================================================ >TO SEE MESSAGE POSTING GUIDELINES: >Send a plain text email to [EMAIL PROTECTED] >In the message body, put just two words: INTRO rbase-l >================================================ >TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] >In the message body, put just two words: UNSUBSCRIBE rbase-l >================================================ >TO SEARCH ARCHIVES: >http://www.mail-archive.com/rbase-l%40sonetmail.com/ ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
