Paradox Community

Items in pnews.paradox-dos

Subject:Re: date grief
Date:Tue, 12 Dec 2017 07:28:10 +1000
From:Bernie van't Hof <berniev@bje.com.au>
Newsgroups:pnews.paradox-dos
CALC 24-Jun-2016-1-22-Jun-2016 => OK (1)

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.
> http://www.avg.com
> 


Copyright © 2004 thedbcommunity.com