Dawn: Excellent explanation. One for the tip list.
bruce/safesectors > -------- Original Message -------- > Subject: [RBASE-L] - Re: Fwd: [RBASE-L] - Row Total Calculation > StoppedWorking in 2 Forms > From: "Dawn Hast" <[email protected]> > Date: Fri, August 07, 2009 6:56 am > To: [email protected] (RBASE-L Mailing List) > > > Ed, > > My understanding is EQNull and ZERO are off by default. So if your cfg file > was refreshed with a new copy, they would get set off. > > I'm not sure if there's anything more in the help that would explain more, > but you can check Razzak's "From The Edge" documents: www.razzak.com/fte. > > Here's my take: EQNull should be off to be in line with SQL standards. > Basically, by setting it on, you're saying that NULL is equal to NULL. Which > is technically not true (again, according to the standard). NULL is not equal > to anything, not even another NULL value. So if variable vara is NULL and > variable varb is NULL, with EQNull set OFF: > > This does not evaluate: > IF vara = .varb THEN > > and this does not evaluate: > IF vara <> .varb THEN > > Even if one of them is NULL, with EQNull set OFF, they don't evaluate. > Having said that, if you haven't gone through your code to determine if any > of the IF vara = .varb could have nulls, you may want to leave it ON. > > The ZERO setting is why your calculations work now. Leave it on if you > expect to evaluate any calculation that may contain a NULL. With ZERO on, it > treats a NULL as a ZERO in calculations only. > > With ZERO On: > > vara = 2 > varb = NULL > varc = 2 > vard = vara + varb + varc > vard = 4 > > With ZERO OFF: > vard IS NULL > > I hope I helped a little. I know especially EQNULL can be a little confusing > and difficult to explain (at least for me!) > > Dawn > -------------- Original message from Ed Rivkin <[email protected]>: > -------------- > > Dawn, > Thanks so much for pointing me in the right direction. Both EQNull and Zero > were > set to off. I turned them both on and will need to review the results through > the rest > of my application. Both calculations are working again. > > I cannot recall comparing for null values anyplace so EQNull On is probably > where > that setting should stay. I need to evaluate the Zero settling. > > Do you know if there is some additional verbiage on each of these settings > and others > that changed significantly in treatment from 4.5 - 7.6. I couldn't find > anything in the > 7.6 Database Conversion Guide. The help text is somewhat limited. > > Finally, any idea how they got toggled off. The calcs were working until I > posted > this somewhat panicky note earlier today. > > Thanks again, > Ed > > Aug 6, 2009 03:16:15 PM, [email protected] wrote: > > Ed, > > Check to see if any of the fields (Rent, Late Fees, Bounced Check Fees) are > NULL (vs ZERO). Then check your EQNULL and ZERO settings. There's a big > difference in the way 7.6 handles nulls vs 4.5. > > Dawn > -------------- Original message from Ed Rivkin <[email protected]>: > -------------- > > While stuck with this problem I also discovered that the calculated field in > the > Rent roll file is no longer working. It's the same calculation as the > variable on > the form and has been in the application since it's inception 19 years ago. > > Case sensitivity is not checked. > > > Aug 6, 2009 11:52:08 AM, [email protected] wrote: > > Hi folks, > Just when it seemed safe to go back into the water another wave hit. > > My forms for Rent entry were converted from 4.5 to 7.6. One of the > variable calculations in the form is adding Rent + Late Fees + Bounced > Check Fees and then subtracting Amount Received to display the > balance for the particular line. This is in a scrolling region. The variable > to calculate balance is defined at the top of the form. It's a very simple > calculation and has worked well until this week. > > The previously displayed balance is now null. I thought the failure might be > due to all the work I was doing working on this form adding in the default > dates for Bankdate and Postdate...my Date/Time Picker thread. > > I reverted to an older copy of the DB, Forms, etc. and reapplied the > enhancements for default date processing. Everything was working great > the last two days and then the same problem resurfaced. BTW, I have > use two different forms for this and am getting the same result. I also > have the original copies of these forms (before I added code for default > date processing) and am now getting the same result with them. > > Thanks for any and all assistance. > > Ed --- RBASE-L =======================3D=======================3 D= TO POST A MESSAGE TO ALL MEMBERS: Send a plain text email to [email protected] (Don't use any of these words as your Subject: INTRO, SUBSCRIBE, UNSUBSCRIBE, SEARCH, REMOVE, SUSPEND, RESUME, DIGEST, RESEND, HELP) =======================3D=======================3 D= TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [email protected] In the message SUBJECT, put just one word: INTRO =======================3D=======================3 D= TO UNSUBSCRIBE: Send a plain text email to [email protected] In the message SUBJECT, put just one word: UNSUBSCRIBE =======================3D=======================3 D= TO SEARCH ARCHIVES: Send a plain text email to [email protected] In the message SUBJECT, put just one word: SEARCH-n (where n is the number of days). In the message body, place any text to search for. =======================3D=======================3 D=
