Great reply.

In the mean-time, and before considering the details of parsing, all we 
have to work with is observations. If the basic rules can be 
established, then parsing, as you say, follows.

There's no point trying to convert known dud queries, as, like Michael 
says, they are unlikely to appear in working code anyway. Where 
possible, let the converter flag the error (or its own limitations) and 
halt.

Consider these pdox test results:
Note: I'm deliberately not using spaces - they make no difference.

1) 23-Jun-2016 => gives expected result (23-Jun-2016)

2) 23-Jun-2016+1 => gives expected result (24-Jun-2016)
2a) 23-Jun-2016+1+1 => gives expected result (25-Jun-2016)
2b) 23-Jun-2016+1-1 => gives expected result (23-Jun-2016)

3) 1+23-Jun-2016 => "Wrong type" error.
3a) 1+1+23-Jun-2016 => "Wrong type" error.

4) 1+23-.. => no err, no result even where data has dates with day = 24.

5) 23-..+1 =>           --ditto--

#3 implies a rule: "in a date calc, the left part must be type date"

************************************************************************
#4 smells like a bug as it is inconsistent with the rule implied by #3
#5 hints at problems with calcs in wildcard dates.
Both #4 and #5 results are, to say the least, strange.
************************************************************************

Possibly the bug is simply that an error is not produced.

*** IF ***   #4 and/or #5 is a bug, then a simple rule emerges:

"No calculations allowed on date expressions containing wildcards".

And in my tests this is consistent pdox behavior. If this rule is valid 
then the entire debate about wildcard date calcs is moot.

What do you think?
******************


Interesting approach using separate selectors on known parts.
     My "Pcode" would be:
     (Day(Date) == 21 and Year(Date) == 2016) + Days(2).
That would be challenging to convert to SQL, I think?

I have been focusing on simply rebuilding wildcards into value.
     23-.. becomes LIKE '23%' in SQL, harnessing the virtually identical
           wildcard handling.

But then you go on to say
     "you could end up with zero matches if you resolve to 25-.. which is
     likely not what you want."

Then what might it be "you want"? I don't get it.

Based on what you say the result may not be the obvious one. Gets more 
obtuse than a hooman bean can handle.

- Bernie
On 11/12/17 11:16 am, Leslie wrote:
> 
> 
> On 11/12/2017 1:59 AM, Bernie van't Hof wrote:
>> Leslie, you make it all sound so easy.
> 
> It is easy when you have the specification in your hand, without it you 
> have no choice but to go back to basic mathematics. But still not too hard.
> 
> 
>> But if we can be practical for a moment, what are the expected outcomes
>> of the following PDOXDOS4.5 queries?
>>
>> CCP Default date format is DD-Mon-YY
>>
>> QUERY
>>
>> Tbl | Date          |
>>     | CHECK 2+23-.. |
>>
>> ENDQUERY
> 
> This could be interpreted multiple ways as there are no brackets 
> indicating the order of operator precedence.
> 
> But I would treat .. to have the highest order (higher than both the / 
> and * operators in numeric calculations actually) and resolve the 
> pattern 23-.. first.
> 
> And then because there is no Day, Month, Year function specified around 
> the 2, I would default to the number being in days because we know this 
> is a date field and since "forever" date API's uses days unless 
> otherwise specified.
> 
> Thus the pattern gets resolved first and then add two days to the 
> result. So the "pcode" would build to something like:
> 
> Days(2) + (Day(Date) == 23)
> 
> I would be interested in what actual result your test data delivered, 
> because if you get it wrong (and by wrong I mean not as expected) then 
> you could end up with zero matches if you resolve to 25-.. which is 
> likely not what you want.
> 
> 
>> QUERY
>>
>> Tbl | Date                 |
>>     | CHECK 21-..-2016 + 2 |
>>
>> ENDQUERY
> 
> Again the + 2 is done after the pattern matching on the date as per the 
> operator precedence rules.
> 
> My "Pcode" would be:
> (Day(Date) == 21 and Year(Date) == 2016) + Days(2).
> 
> Looks simply with hard-coded values, so using a Parameters for the year:
> 
> CHECK 21-..-~Parameter + 2
> 
> would resolve to:
> (Day(Date) == 21 and Year(Date) == ~Parameter) + Days(2).
> 
> If the result is not what the user wanted or they suspect it may not 
> resolve the way they want it then a smart user would do the following:
> 
> CHECK 21-..-(~Parameter + 2)
> 
> which the expression evaluator would resolve to:
> Day(Date) == 21 AND Year(Date) == (~Parameter + 2)
> 
> Of course if it were me I would code my expression parser to parse 
> left-to-right and produce postfix representions of infix expressions as 
> it makes the actual expression evaluation simple(r).
> 
> I suppose I am 30+ years too late saying this but those of us from a C 
> world understand the need for brackets especially when using pointer 
> arithmetic. My philosophy has been why not throw a few brackets in there 
> to help things along a bit even in SQL script.
> 
> 
> Anyway, this is where things can get tricky, because now we are asking 
> is the goal a complete emulation or not?
> 
> If it is an emulation then the bugs must also be emulated. If this is a 
> translator/conversion then some leeway is allowed and undefined results 
> need not match, they are simply undefined.
> 
> So based upon your goal, yes you need the QBE specification specifically 
> used by Paradox for DOS. My guess is that ODAPI kept the same rules and 
> thus so did the BDE. But the Borland guys may have fixed/changed things 
> along the way - this is what we do not know.
> 
> So, is this an actual emulation or a translation project ?
> Interesting either way !
> 
> Leslie.
> 
>> NB: They do not throw errors.
>>
>> - Bernie
>> On 10/12/17 9:47 pm, Leslie wrote:
>>>
>>> On 10/12/2017 7:54 AM, Michael Kennedy wrote:
>>>
>>>> Yes - thinking of how to parse numerous "-", ".", "..", and "/" 
>>>> chars is
>>>> frightening... I expect there are numerous "expressions" that could be
>>>> validly interpreted in multiple, totally different, ways.
>>>
>>> Parsing is not the issue - many of us had to write language parsing
>>> rules in the 80's as a mere exercise.
>>>
>>> What *is* the problem is knowing what the existing rules for QBE in
>>> Paradox are so that we parse the file/string correctly.
>>>
>>> I have been looking through my archives for the QBE specification this
>>> afternoon and have not had any luck at this time. I do have a copy of
>>> the book "Paradox Queries" by Dan Ehrmann but Bernie wants a Paradox
>>> for DOS specification which makes that one too modern.
>>>
>>> I will keep looking, but if I do not have any luck, I will email a few
>>> team mates from the 80's to see if they kept the original QBE
>>> specification - I know it exists because I had a photocopy from
>>> Borland Australia (back when they were helpful).
>>>
>>>
>>>> And, I've always had huge respect for the folks who developed the
>>>> internal ISAM/B-Tree handling, record locking, etc.
>>>
>>> How it works is nothing special really, in fact quite common back then.
>>>
>>> IMO, what makes a Paradox database (on Windows) that little bit extra
>>> special over others of the time is the ODBC interface and support by
>>> third party tools such as Crystal Reports.
>>>
>>> I co-wrote something similar back in the late 80's which we used in
>>> parallel with Btrieve 3.5/4.0.
>>>
>>> I have rewritten that library twice since then as I use it in other
>>> applications today. It does super-fast data retrieval (faster than
>>> Paradox actually) and does not need an engine like the BDE. If only it
>>> had an ODBC interface, but I am 25 years too late on that one.
>>>
>>>
>>>>> That they got as far as they did is testament to their skill, but the
>>>>> hole they were digging was getting deeper and filling up with edge
>>>>> cases.
>>>
>>> The hole they dug was to under-appreciate their developers. Once the
>>> external Marketing people got into the heads of Borland management
>>> they were finished. IMO, Borland peaked around 1992 and it has been
>>> downhill since then, a real shame.
>>>
>>>
>>>>> As it is unlikely I can do better than they did and even less likely I
>>>>> could reproduce all their outcomes, I might have to introduce some
>>>>> little rules. We'll see.
>>>
>>> As I have previously suggested, the standard practice is to create a
>>> configuration file which allows you to specify default rules but then
>>> allows the installer/caller to alter them.
>>>
>>>
>>>> I think that would be entirely acceptable. Also, I expect most/all
>>>> developers got burned with numerous "odd" expressions, and that they,
>>>> therefore, used only very safe and conservative code, and kept far away
>>>> from all the edge conditions that you've observed.
>>>> Mike
>>>
>>> Exactly, creating a rule/configuration file is the smart approach and
>>> if you code that in from the beginning it costs almost no additional
>>> time and gives you flexibility forever.
>>>
>>> Leslie.
>>>
>>>
>>> ---
>>> This email has been checked for viruses by AVG.
>>> http://www.avg.com
>>>