Ran into another one this morning...
JQL now appears to be doing string comparison rather than value comparison
when dealing with the value of zero.
For example, to process every record in IM with a non-zero quantity on hand.
SELECT IM WITH QOH NE 0
Previously this excluded records with a QOH
Might be better SELECT IM WITHOUT QOH = 0 which is actually what you
stated you want.
Dan Ell
From: jbase@googlegroups.com [mailto:jbase@googlegroups.com] On Behalf Of Darrin
Sent: Monday, February 04, 2013 9:51 AM
To: jbase@googlegroups.com
Subject: Re: jBASE migration 3.4 to 5.2 - How
*jBASE 5.2 appears to work identically to jBASE 3.4.*
*
*
*On jBASE 3.4:*
*
*
*jsh ~ --LIST IM QOH*
*
*
*IM QOH*
*
*
*1 *
*20 *
*
*
*jsh ~ --SELECT IM WITH QOH NE 0*
*
*
* 1 Records selected *
*
*
**
*
*
*Dan Klein*
On Mon, Feb 4, 2013 at 9:50 AM,
Of
Darrin
Sent: Monday, February 04, 2013 9:51 AM
To: jbase@googlegroups.com
Subject: Re: jBASE migration 3.4 to 5.2 - How difficult?
Ran into another one this morning...
JQL now appears to be doing string comparison rather than value comparison
when dealing with the value of zero.
For example
[mailto:jbase@googlegroups.com] On Behalf Of Darrin
Sent: Monday, February 04, 2013 9:51 AM
To: jbase@googlegroups.commailto:jbase@googlegroups.com
Subject: Re: jBASE migration 3.4 to 5.2 - How difficult?
Ran into another one this morning...
JQL now appears to be doing string comparison rather than
Interesting, so you're seeing different behavior than us. We use
JBCEMULATE=ROS if that makes any difference.
jbase 3.4:
:SELECT IM WITH QOH NE 0
909 Records selected
:SELECT IM WITH QOH 0
909 Records selected
:SELECT IM WITHOUT QOH = 0
909 Records selected
jbase 5.2:
You're right that the ROS emulation behaves differently but, as far as I'm
concerned, it's a bug on jBASE 3.4.
Does Reality actually behave that way?
Dan
On Mon, Feb 4, 2013 at 1:10 PM, Darrin djfi...@yahoo.com wrote:
Interesting, so you're seeing different behavior than us. We use
I seem to remember that back in kBASE 3.4 there was a setting in the
jbase/config/Config_EMULATE to treat null and zero as the same.
Not too sure if 5 carries the same.
KDB
On Sunday, January 27, 2013 4:03:32 PM UTC+13, Kevin Powick wrote:
How much hassle is a migration from jBASE 3.4 on
The null_eq_zero configuration option only affects the 'sorting' of 'nulls'
and 'zeros'; it has nothing to do with SELECT'ing.
From the '$JBCRELEASEDIR/config/Config_EMULATE.txt' document:
Right justified Null fields will sort equal to zero.
Dan
On Mon, Feb 4, 2013 at 4:47 PM, Ken Brown
To: jbase@googlegroups.com
Subject: Re: jBASE migration 3.4 to 5.2 - How difficult?
The null_eq_zero configuration option only affects the 'sorting' of 'nulls'
and 'zeros'; it has nothing to do with SELECT'ing.
From the '$JBCRELEASEDIR/config/Config_EMULATE.txt' document:
Right
On Tuesday, January 29, 2013 3:46:37 PM UTC-5, Kevin Powick wrote:
On Tuesday, 29 January 2013 13:55:19 UTC-5, Darrin wrote:
Also, somewhere between a 1/3 and 1/2 of our basic programs have needed
code changes. Most of those changes are minor
I know you said it affected hundreds of
Darrin,
On Friday, 1 February 2013 08:16:24 UTC-5, Darrin wrote:
Most of the changes were simple, involving just syntax changes to existing
lines of code rather than progromatic flow or logic changes. However there
definately more changes required than I had anticipated.
Thanks for the
Kevin,
You are probably going from 32-bit to 64-bit. However, if your code is all
traditional MV BASIC style code I don't think that you will have a problem.
We have struggled because of hooks outside of jBASE that have caused us
conversion issues. I don't blame this on jBASE. It is a matter
I'm in the middle of a 3.4 - 5 linux based conversion right now. That also
means a 64 bit conversion. Because everything needs to be recompiled, the
tough call is on how thorough of re-validation is necessary.
Also, somewhere between a 1/3 and 1/2 of our basic programs have needed
code
On Tuesday, 29 January 2013 13:55:19 UTC-5, Darrin wrote:
Also, somewhere between a 1/3 and 1/2 of our basic programs have needed
code changes. Most of those changes are minor
I know you said it affected hundreds of program files, but is it only a
handful of code incompatibilities? Can
On Tuesday, 29 January 2013 04:58:23 UTC-5, Dick Thiot wrote:
However, if we hadn't done what we did then we probably wouldn't have
the functionality that we do also! ;-)
Yes, one can often find themselves weighing the decision of whether or not
to take advantage of a feature that
Dan,
Thanks for the input.
Fortunately, this system isn't very large nor complicated. Also, IIRC, the
programs were all written keeping cross-mv-platform migration in mind. So,
I don't think there is anything too fancy going on with the code.
I guess what I really need to do is get a
How much hassle is a migration from jBASE 3.4 on Windows to jBASE 5.2? It
is not required that the 5.2 platform be Windows, but the client would
prefer if it was.
--
Kevin Powick
--
--
IMPORTANT: T24/Globus posts are no longer accepted on this forum.
To post, send email to
18 matches
Mail list logo
