Paradox Community

Items in pnews.paradox-dos

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


Copyright © 2004 thedbcommunity.com