Paradox Community

Items in pnews.paradox-dos

Subject:Re: date grief
Date:Tue, 12 Dec 2017 08:03:56 +1000
From:Bernie van't Hof <>
And how about:

CHECK calc 24-Jun-2016-2..
CHECK calc 24-Jun-2016+2..
(same result)

============ 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

- Bernie
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 
> well.
> 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).
> Leslie.
> ---
> This email has been checked for viruses by AVG.

Copyright © 2004