Leslie.. absolutely correct.. anything with a dot-dot is a pattern match, 
not a field-type evaluation.. and like I said earlier, and Bernie just 
quoted me as saying.. all these years, the idea of putting a dot-dot in a 
math statement never occurred to me.. I am shocked that it works, because of 
the way the dot-dot stuff works


--

Steven Green
Myrtle Beach, South Carolina, USA

http://www.OasisTradingPost.com

Collectibles and Memorabilia
Vintage Lego Sets and Parts
- and Paradox support, too
"Leslie"  wrote in message news:5a2e9111@pnews.thedbcommunity.com...

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 


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus