Sorry, Marc, you're right. EQNULL is a little more insidious. It means that an expression like...
IF myvar = someothervar THEN ... will be evaluated as true if both sides of the operator are null. Or: "if I don't know this, and I also don't know that, then they must be the same." Bill On Fri, Apr 11, 2008 at 8:55 PM, Marc <[EMAIL PROTECTED]> wrote: > Hi BIll > > I thought that was Set Zero On? > > Marc > > > ----- Original Message ----- > *From:* Bill Downall <[EMAIL PROTECTED]> > *To:* RBASE-L Mailing List <[email protected]> > *Sent:* Friday, April 11, 2008 7:47 AM > *Subject:* [RBASE-L] - Re: EQNULL ON or OFF > > Marc, > > When EQNULL is on, R:BASE doesn't distinguish a null from a zero, so any > average calculations are screwy. > > Bill > > On Fri, Apr 11, 2008 at 8:41 PM, Marc <[EMAIL PROTECTED]> wrote: > > > > > After reading the other thread I got nervous about my EQNULL setting. > > I have it set to ON, so now I am worried. I had a problem sometime back > > and setting EQNULL ON fixed that problem so I just leave it on. > > > > What are the dangers with it ON? > > > > thanks > > Marc > > > > > > > > ----- Original Message ----- From: "Lawrence Lustig" < > > [EMAIL PROTECTED]> > > To: "RBASE-L Mailing List" <[email protected]> > > Sent: Thursday, April 10, 2008 7:21 PM > > Subject: [RBASE-L] - Re: Testing for field diferences. > > > > > > << > > > Interesting thought but I refuse to futz with the EQNULL option. > > > It is not standard SQL and can have unwanted side effects. > > > > > > > > > > > > > > > You can do this more or less safely like this: > > > > > > SET VAR vSaveEQNull = (CVAL('EQNULL')) > > > SET EQNULL ON > > > IF <<Condition Here>> THEN > > > -- Do Stuff > > > ENDIF > > > SET EQNULL &vSaveEQNull > > > CLEAR VAR vSaveEQNull > > > > > > As long as your confident in the IF statement and the nested code, > > > this will do what you want without endangering the database wide EQNull > > > setting. > > > -- > > > Larr > > > > > > > > > > > > > >
