Karen, My guess is that the $8 represents the "NULL" internal value actually used to represent a NULL value. Way back when I was updating older to newer versions of RBase I had a problem with NULL values.
In my opinion I would alter the Table Definition to add DEFAULT values to those fields of $0.00. Quite possibly I would also make the NOT NULL. sit that cikuns would always require a value. Also a RULE for each column requiring say a value of $0.00 or greater be required. Jim Bentley American Celiac Society [email protected] tel: 1-504-737-3293 >________________________________ >From: "[email protected]" <[email protected]> >To: RBASE-L Mailing List <[email protected]> >Sent: Tuesday, October 11, 2011 9:14 AM >Subject: [RBASE-L] - Guarantee you've never seen this problem.... > > >Wow, this one beats everything I've seen since going back to RBase System V >days... > >Converting a client from dos, I did not create this database, working with 7.6 >but I tried it in 9.1 and the same problem is there. Form is based on >Invoices table. We have a test database set up there, and they reported an >error. Of course, it works perfectly fine in my test environment here. > >This is going to be really hard to describe.... I'm sure I will confuse you >all, but here goes. > >The table has a computed column, all datatypes are Currency >InvTot (INVSUB+ ADDED01+ ADDED02+ INVTAX+ FREIGHT) > >Displayed on my form is a variable to display that: >vInvTot (.vInvSubCurr + ADDED01 + ADDED02 + .vTotalTax + FREIGHT) > >The 3 columns Added01, Added02 and Freight are directly editable on the form >using DBEdits. For vInvSubCurr and vTotalTax, these are form expressions >that rely on editable variables; these are not presenting any problems. > >Here's the problem: Someone changes a field that causes vInvSubCurr or >vTotalTax to be re-evaluated, which causes the formula for vInvTot to be >re-evaluated. If any of those 3 DBEdit fields (Added01, Added02, Freight) are >empty, it evaluates that field as having the value of $8 when adding up >vInvTot!!! If I put actual values in those DBEdits, even $0, then vInvTot >adds up fine. But leave any of them blank, and it adds an $8. However, the >table data is perfectly fine -- it does NOT store those $8 values, all 3 >columns would stay null and InvTot is perfect. So the problem isn't with my >data, it's the fact that displaying the vInvTot form on the screen shows the >incorrect total. > >How I found the $8 thing: I created form variables like: vAdded01 = Added01 >and put them on the form alongside the DBEdits for all 3 of those fields. >When the form initially loads for a row where all 3 fields are null, all 3 >varaibles show $0 correctly. But as soon as I type something in one of the >other fields that causes vInvTot to reevaluate (part of vInvSubCurr or >vTotalTax calculations) then you see the variables change to $8, although the >3 DBEdits stay blank!! > >Things I checked and did: >1. The DBEdit controls do NOT have a default value in the properties tabs. >2. Went into RBDefine to verify there is no default value in the columns. >3. I started a form from scratch putting in just a half dozen fields to >test this, and it's the same $8 wrong values!! So my form isn't corrupted. >4. Database auto-checks okay and reloads okay. Did an "unload all" and it >works incorrectly on the unloaded database!! >5. My Set Null can be set to either -0- or a blank, no difference. Set >EqNull ON or OFF also makes no difference. >6. I brought their database to my computer here, and it works incorrectly, >so it's not a hardware/OS difference between me and them. > >So am I right? Is this really screwy? It points to a database problem or >setting issue since (1) it works fine here, (2) creating a new form displayed >the same error, (3) their database works incorrectly here. Is there any other >kind of setting you can think of that I need to change?? (I did a quick >workaround by issuing a NEXTROW command after the editable fields; since the >form is only brought up for 1 invoice at a time, this causes the row to >refresh and show the correct null values in the calculation.) > >Karen > > > > >
