|Subject:||Re: date grief
|Date:||Tue, 12 Dec 2017 08:03:56 +1000
|From:||Bernie van't Hof <firstname.lastname@example.org>
And how about:
CHECK calc 24-Jun-2016-2..
CHECK calc 24-Jun-2016+2..
============ Answer ==========
ANSWER | Date | Blank |
1 | 1-Jan-2011 | |
2 | 23-Jun-2016 | |
3 | 24-Jun-2016 | |
4 | 25-Jun-2016 | |
In contrast to:
CALC 24-Jun-2016-24-Jun-2016 => OK (0)
CALC 24-Jun-2016+24-Jun-2016 => "Type Error"
I think we're done: MATH + WILDCARD = ERROR
On 12/12/17 12:07 am, Leslie wrote:
> I have been thinking about the leading Zero problem as per Dan Ehrmann.
> Now this may not need to be said, but I will say it anyway as it may
> help explain some of the results.
> The fact that ../9/.. does not match records when it should, but
> ../09/.. does is actually quite important.
> What this tells me, and I am ready to stand corrected, is that Paradox
> is not performing any true evaluations with .. and probably @@ as well.
> What I think Paradox is doing is retrieving the value from the record
> and constructing it into its display format and holding as a string.
> Then it is doing a string comparison, whilst also catering for
> wildcards. So ../9/.. will never pattern match 01/09/2016 which is an
> example of what gets constructed - hence an empty result set.
> This is completely different from how I would do it, which would be to
> retrieve the date, extract the Day, Month and Year components and
> compare their values with those specified in the QBE (which I would also
> convert to shorts in the process). In other words no pattern matching
> occurs which removes the need for display formatting information.
> However, they did not do this as it might have been too expensive in
> terms of the code required (we only have 640K remember).
> So, this means that Paradox really is doing pattern matching when a ..
> operator is present. This may also be true for other types of fields as
> well, in fact I would put money on it.
> But do not forget that Dan also states that 5/9/89 does return the
> correct result set without needing the leading zero. In this scenario, I
> believe that Paradox is doing binary matching and so the display format
> never comes into play.
> Therefore, and I think this is what Bernie shows with his results, QBE
> expressions get evaluated using an entirely different algorithm when ..
> is present and that is likely always as a string and possibly for any
> field types.
> I also think I can explain the 1+ and +1 before and after the pattern as
> 1 + Date pattern should be able to be evaluated like Date Pattern + 1
> does. Instead we get the Wrong type error.
> Upon reflection I think this is due simply how they parse the Date
> expression to extract out the date pattern itself. So they are parsing
> left to right in a single pass and then when they hit a non-date
> operator *after* the *date* expression/pattern they then syntax check it
> probably to make sure they got a valid pattern.
> At this point we get the Wrong Type error (but Syntax Error might have
> been a better message).
> Operators after the date do get evaluated correctly as they have already
> processed/evaluated the pattern match and so they can then apply date
> arithmetic as they continue on their merry way parsing left to right.
> A bit of a mess and I would need to test this theory out to be sure, but
> what it comes down to is that some things could be done for cheap or
> even free in terms of the coding, but others could require something
> more complex such as multiple passes, which would require more memory.
> So, fancy stuff got dropped and this was all probably documented. We
> just don't have that documentation.
> So to conclude, I think that once the wildcard operators are present
> Paradox then does string matching and this can cause strange results to
> be produced as Bernie reports.
> It makes sense (to me at least).
> This email has been checked for viruses by AVG.