Dave Shaw wrote:
>
> I seem to remember something about this coming up on the list
> recently but I can't find the reference. Anyone else remember what
> happened? I'll keep looking.
>
Dave, I asked the question and below is the response from Jack:
This "feature" can be fixed by going into the field definitions for each
of
the fields in names_.102 whose name begins "Sum:" and unchecking the box
for "Do Not Evaluate if All Referenced Fields Are Empty".
>I've run across an oddity in v.1.02 that may cause query difficulties
>and has me a bit baffled. When I run Replace All Find Fields, records
>without payments get the Home Screen fast find fields set to blank.
>When I run the Replace Current Find Fields, though (such as when I
>toggle back to the Home screen from another), those fields are set to
>$0.00. This means that the value for some records with no payments
>differs depending on whether or not any given record has been toggled
>(or otherwise had the Replace Current Find Fields run on it).
>
>What this means is that if I query for blank fields ("=") vs fields with
>values of $0.00 ("0"), I get very different results (only those I've
>toggled come up as $0.00, whereas "=" yields records that I haven't
>toggled). While I won't likely run that query alone, I might as a part
>of a many layered query. Thus, using a query for ">0" and omitting the
>found records (which should work to locate all records w/o payments)
>this creates a large opportunity for error with many layered queries.
>
>Furthermore, v.1.00 doesn't work this way. Both scripts result in $0.00
>for records with no payments. In fact, Dave Shaw and I discussed this
>and he wondered if it could have to do with the check box on the
>SUM:Current Fiscal Year field being set to Do Not Evaluate if All
>Referenced Fields Are Empty. But that is the case for both v.1.02 and
>v.1.00 (both calculations are checked for this).
>
>Do you know what's going on here and whether or not there was a reason
>for this? If not (i.e. if the Replace All script should return a
>$0.00), then what's the fix?
>
>Secondly, this issue brings up a bigger issue for me. Will you folks
>continue to provide access to v.1.02 after V2 is released? And further,
>will you continue to provide listserv support for v.1.02 (it might need
>to be separate from V2 support as much confusion could result
>otherwise)?
>
>I am uncertain if we will update to V2 because our needs are modest and
>V2 will be more complex. It may not be worth our upgrading. Others may
>feel similarly. Also, I may suggest to some small groups that v.1.02 is
>a better solution for them, depending on just how V2 looks (and the
>availablity of teh database and support for it). In all cases above, it
>would be helpful to have continued support for v.1.02.
>
>AND... This suggests that the v.1.02 on the web site should have the
>SUM:CurrentFiscalYear field fix implemented so that people download a
>repaired version and don't have to struggle with the glitch and it's
>fix. I know Bob was going to look into this for me, but I haven't heard
>whether or not the fix was implemented in the version that is currently
>available. (This seems like a simple change that could be implemented
>quite quickly).
>
>Thanks for any advice you can give me.
>
>And, I hope you will keep 1.02 available with support and that you won't
>abandon us small folks...
>
>Carl
--
Carl Paulsen
New Hampshire Rivers Council
54 Portsmouth Street
Concord, NH 03301
603-228-6472
603-228-0423 Fax
[EMAIL PROTECTED]
------------------
Reminder to each recipient: To change your list account preferences, go to
http://email.sparklist.com/scripts/lyris.pl?enter=support and enter the email address
you used to subscribe to the ebase support list:: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]
---------------------------------------------------------------------
ebase - Relationship Management for Nonprofits, http://www.ebase.org
---------------------------------------------------------------------
