Paradox Community

Items in pnews.paradox-dos

Subject:Re: date grief
Date:Mon, 11 Dec 2017 12:10:00 +1000
From:Leslie <"ViaThe List"@NOSPAM.com>
Newsgroups:pnews.paradox-dos
Hi Bernie,

If I might just add this as a general statement....

One of our applications was built Using Visual C/C++ version 6 and we 
are currently in the process of migrating to Visual Studio 2015.

The application is written in pure ANSI C so nothing has really changed 
in the standard as the main changes are in the C++ side of things.

What are the expectations in this scenario?
Many would just expect the thing to compile and work, that is not the 
case and I have done many "like for like" compiler upgrades over the years.

Minor code changes have been required to make everything compile and in 
the case of that single index database library I mentioned it goes much 
further.

The original code was written back when the BYTE keyword did not exist, 
so we used chars. Now by definition an ANSI char is 8 bits. However, 
what has changed is that the compiler now defaults to signed chars 
rather than unsigned. Not a problem until the char is used as an index 
offset then we ran into trouble.

So:
	char c;
	x = array[c];

Works fine until c hits 128, then the index goes negative (-127) and 
then we are walking through memory.

The two choices are to change to:
	unsigned char c;	or
	BYTE c; 	// which I prefer

My point is that, for the project you are doing Bernie, anyone who 
expects it just to work and to work the same as Paradox for DOS is 
fooling themselves. And this is more than just a compiler upgrade, this 
is an environment change, so a far bigger deal.

Anyone migrating code into your final environment will need to do a 
complete system test. One of my tests would be to ensure that all QBE's 
and SQL statements get executed as expected and the expected result set 
gets returned.

So, do not be too hard on yourself with some of the fringe decisions, go 
with what is logical and you should be fine.

I'll keep looking for any documentation.
Leslie.




On 11/12/2017 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
>>>


Copyright © 2004 thedbcommunity.com