Sorry to be redundant but 1,000 thanks for the comprehensive explanation. What is
throwing me a bit is how zero "got toggled" to off at that point. I had been working
with the code and db in 7.6 for quite some time and was not in the cfg file playing
with or reviewing settings.
Your thorough explanation set me straight. Again my thanks.
Take care,
Ed
Aug 8, 2009 09:18:37 AM, [email protected] wrote:
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
