Subject: | Re: date grief
| Date: | Mon, 11 Dec 2017 17:48:04 +1000
| From: | Bernie van't Hof <berniev@bje.com.au>
| Newsgroups: | pnews.paradox-dos
|
On 11/12/17 3:48 pm, Leslie wrote:
>> What do you think?
>> ******************
>
> I agree with what you have written. I think that Paradox is not
> producing error messages when it should.
Hooray!
> What occurs if you use a M/D/Y format and do the same tests. Does
> 1+6/1/2016 work and also then what about 1+6/../..
TBA
> The Date query ../9/.. finds no records on the same table. No error
> message, nothing.
Sounds like another in the same vein
> The conclusion is there are bugs
Copy that.
> Yes that is one approach, but it might be easier to build your own
> middle pcode/token layer as compilers do and then use that to generate
> the equivalent SQL expression or whatever the target actually is. So
> multiple passes could/would occur.
Maybe, but beyond my experience! I'm winging this remember! There are
some really detailed docs out there from IBM on the languages of QBE.
Too complicated for me I'm afraid.
> I think 2+23-.. should return all dates with the day being 23 and then
> add two days to the result.
If the query is CALC yadda yadda then maybe, but failing that the
content is merely a selector. Anyway if we have eliminated wildcard
calcs it really doesn't matter.
> Now what if you do CHECK 12+23-..
Agree, it just gets sillier and sillier.
> If you write an expression converter/generator you will find the whole
> process a lot easier and feel less overwhelmed I think.
Well it is 2017! Nearly 2018!
> The expression parser could then be used all over the show and in
> different projects because done correctly it can be universal and thus
> portable.The stream component is shared, the lexer is shared but with different
keyword sets, the parser is different for PAL and QBE and then QBE
splits further for different column types. Ain't OO grand!
> So for sure you are going to find bugs, but should you duplicate them or
> not. *That* is the question ?
I share Michael's thought that pdox developers have all been down the
path of finding that certain things didn't work as expected and found
ways around them. Usually to simplify. So as they knew certain things
didn't work, they won't show up in their code.
I'm only finding these bugs because I'm throwing a zillion variants at
qbe to see how it responds and figure out some rules. Going forward I
imagine it will be easier to write any new queries in SQL as that is
easy to support.
Like Steven said back in October: "I've never done that, or seen that,
in 30 years of working with PDoxDOS", but there ya go!
- Bernie
|