Assignments to uncast dummy fields (was Re: simple comparison failing)
Nancy Palmquist
nlp at vss3.com
Fri Feb 15 09:29:20 PST 2008
Tyler,
As Ken said, this is one of the ways that filepro helps you.
For example:
xx eq "1"
Now to do a proper comparison it has to decide if "1" is literal or numeric.
if XX is not defined, this can go wonky on you. If XX is literal, then filePro
will compare literally. If xx is numeric, then filepro will compare numerically.
Now it does not seem like that would make any difference, but remember all stuff
happens at a binary level not base 10, so some numbers, when converted will not
test true - when they look true in decimal.
I used to do a sample of this in my training classes, and can show examples
where "0" is not equal to "0" - only because the types are not properly defined.
So I have found it very important to compare apples to apples. You can do the
following:
doedit(rr,"*","1") eq "Y"
That would make sure you tested literally.
Be careful with dates listed as literal also and the comparison data. You will
always get the right results if you specify the date format.
For example, what date is this? "040206" is it April 2, 2006 or Feb 6, 2004 or
Feb 4, 2006. All could be assumed from that literal string.
But by adding:
doedit("040206","mdy","6") - now it is clearly Apr 2, 2006.
MORAL: try not to let any default behavior kick in. Tell filePro exactly what
you want by giving edits to variable that must be tested, either with attributes
or with doedit().
I have also found similar issues with dates that are user entered.
For example:
10/01/08 or 10-01-08
will pass the date edit. But if I index these two dates they do not seem to
mesh as you might expect. Had real issues with this.
Solution is simple: normalize all dates by a very simple step
@wlf10 'where 10 is a date field entered by a user
then: 10=10+"0"
The resulting date will always have slashes.
Could be this was behavior that has been fixed in newer filePro versions, but
even if the sorting is not broken any more and the testing is not broken, it
sure makes the data look better.
My history with filePro is long and my memory just as long. Once I learn how to
avoid an issue, it seems to stick with me even after the issue has often been
resolved. So I apologize if this no longer is a problem.
Nancy
--
Nancy Palmquist MOS & filePro Training Available
Virtual Software Systems Web Based Training and Consulting
PHONE: (412) 835-9417 Web site: http://www.vss3.com
More information about the Filepro-list
mailing list