Paradox Community

Items in pnews.paradox-dos

Subject:Re: date grief
Date:Tue, 12 Dec 2017 00:07:15 +1000
From:Leslie <"ViaThe List"@NOSPAM.com>
Newsgroups:pnews.paradox-dos
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