Numeric RI Null = Zero

[peterbruce]

JDEList,

Here is another one from the strange but true files - well in my view anyway. I was investigating problems with some custom UBEs and discovered that the Report Interconnect (RI) numeric variables did not behave as I thought

. I had mistakenly thought that a null value for a numeric RI variable was different from a zero value

.

My investigation so far has been only on a fat client.

I had setup a number of If statements in the UBE to be called to check for Null, Zero, and non-Null/Zero values passed into numeric RI variables and Null, Blank and non-Null/Blank values passed into alpha RI variables. I looked at both literal and variable values mapped to the RI variables in the calling UBE as well as unmapped. In the called UBE I looked at the RI variables and also ER variables set equal to the RI variables.

The results for the literal and variable values mapped to the RI variables in the calling UBE were the same. The results for the RI variables and ER variables set equal to the RI variables in the called UBE were the same. This was as I expected.

The really strange result was that the following if statement proved true

:

If RI NumericVariable is equal to null AND RI NumericVariable is equal to zero

I have attached a zip file containing an Excel (97-2003 version) file holding the results and a text file with the ER extract from the calling and called UBEs.

My system config for the above is:
Oracle JD Edwards EnterpriseOne E8.11sp1 TR 8.97.2.1, ES Sun.

 

[Alex_Pastuhov]

Yes, this is also one of those "as designed" things ;-)

 

[Scott Beebe]

Here is a best practice for checking for non-null, non-zero values. Always write it like this:
If ItemNumber is greater than <Zero>
//Code for dealing with non-zero value
else
//code for dealing with blank, null, and zero.
End If

This statement is the catch all for checking for NULL, BLANK, and ZERO. This works for all variables: Math Numeric, String, Date, & Char. Many times there is only an action for a zero/null. In these cases I only put code in the else portion of the statement.

How many times have you written the same statement like this:
If ItemNumber is not equal to <Zero>
And ItemNumber is not equal to <Blank>
And ItemNumber is not equal to <Null>
//Code for dealing with non-zero, non-null value
End If

 

[peterbruce]

Scott,

[ QUOTE ]
If ItemNumber is greater than <Zero>
//Code for dealing with non-zero value
else
//code for dealing with blank, null, and zero.
End If

[/ QUOTE ]

Thanks for your reply. I will use your solution when I next need to:

[ QUOTE ]
How many times have you written the same statement like this:
If ItemNumber is not equal to <Zero>
And ItemNumber is not equal to <Blank>
And ItemNumber is not equal to <Null>
//Code for dealing with non-zero, non-null value
End If

[/ QUOTE ]

However, the problem I experienced, with reference to the numeric RI variable, was to distinguish between zero and null. Which, it appears, cannot be done.

 

[cscdans]

Hi,
the RI in nothing else than a dtatastructure, and so the single RI-values are DSTR members. JDE never has pointer for mathnumeric (or char or string values etc.). Hence a RI, FI or BSFN Parameter member never can be null, it is blank or zero.
Best regards,
Carsten

 

[Larry_Jones]

Thanks Carsten, in retrospect that makes a lot of sense.

 

[Gary P]

Agreed. It seems strange at first, but makes sense when you look at the underlying code. Thanks to stuff like this, we all have stable jobs, and can feel smart when we explain this to the users.

If you ever need to send in an optional value that may be zero, you can add a flag to the data structure that says so. Then you just compare the flag in the ER.

 

[peterbruce]

Carsten,

[ QUOTE ]
Hence a RI, FI or BSFN Parameter member never can be null, it is blank or zero.


[/ QUOTE ]

I'm not sure I understand. My testing/investigation revealed that a numeric RI variable could not be null or that null was the same as zero. However the string RI variable could be null and different to blank. There is a definite difference between numeric and string RI variables as far as a null value is concerned.

Have I made a mistake in my testing/investigation?

Gary,

[ QUOTE ]
If you ever need to send in an optional value that may be zero, you can add a flag to the data structure that says so. Then you just compare the flag in the ER.

[/ QUOTE ]

This is what I have to do.

 

[barrier]

Peter,

In my 11+ years of digging thru jdedebug logs there is definitely a difference between strings in data structures. If nothing is passed in then the resultant value is null, which is totally different than blank. I have solved numerous issues by passing a blank in the data structure of a business function. Now, that said, perhaps the later BSFNs developed by JDE/PSFT will account for the difference. All I know is that the older BSFNs seldom did.

 

[peterbruce]

Barrier,

I appreciate your comments. I too am no novice when it comes to JDE, having worked with one version or another (World and E1) in an admin/cnc/developer role for approximately 15 years. Your comments confirm my experience, and the possibility that others are refering to newer versions had crossed my mind too.

The fact is that, with the versions I am working with (E8.11sp1 TR8.97.2.1, ES Sun), there is a difference between numeric and string RI variables with regard to nulls, as I have posted in the thread.

 

[Scott Beebe]

Is anyone else thinking the same thing I am? Does it really matter? It is an easy thing to code around so why keep hashing it out? Bottom line is don't use and equality "=" operator to check for null/blank/0.

If you use "variable > Blank" you will find if the variable has anything in it. This means it will true if ti contains a 0.

If you use "variable > 0" you will find if the variable has any value and/or non-zero value. This statement works on all data types to determine if it contains a value. No need to check for 0, null, or blank. No need to know what the data type is.

 

[peterbruce]

Yeah, storm in a tea cup ... you're probably right.

... and if there is an optional variable that may be zero, as Gary said: add a flag to let you know.

 

[Scott Beebe]

Personally, I don't think you would need that. But, everyone has their own way.

 

[peterbruce]

Interesting, Scott. Always eager to learn a new, possibly better method.

The situation the prompted this thread was the need to determine if the UBE had been called from another UBE or run on its own. Relying on a null value in a numeric RI variable, wouldn't work. The only other simple method was a flag or string RI variable. How would it be done a different and hopefully simpler way?

 

[Scott Beebe]

to go back to my previous post:

If RI Variable is greater than <Zero>
//Code for dealing with non-zero value
else
//code for dealing with blank, null, and zero.
End If

This statement is the catch all for checking for NULL, BLANK, and ZERO. This works for all variables: Math Numeric, String, Date, & Char. Many times there is only an action for a zero/null. In these cases I only put code in the else portion of the statement.

If zero will be a valid value you can change it to:
If RI Variable is greater than <Blank>
//Code for dealing with non-zero value
else
//code for dealing with blank, null, and zero.
End If


This replaces doing this code which we have all seen at least once in JDE code.
If ItemNumber is not equal to <Zero>
And ItemNumber is not equal to <Blank>
And ItemNumber is not equal to <Null>
//Code for dealing with non-zero, non-null value
End If

 

[Alex_Pastuhov]

Well, from my POV, you are all off-track ;-)

If you need to tell from a single RI/PO value that it was called from some specific place, just use a hard-coded constant 88888888888 - the chances that this should happen naturally are for all practical purposes 0.

There was a sentiment expressed here before, comparing NULL with a 0 pointer, which is of course correct from a development POV. But I think, we should really be looking from a DB POV in this case and we all know that JDE _never_ uses NULL DB values ever. In JDE, there are no NULL's as such. Or you can say that any blank or 0 = an empty value = NULL (again, from JDE prospective).

And also remeber that '' or 0 can both be legitimate values in some cases, so when comparing with NULL you actually render them unusable.

So, what I'm trying to say, te actual condition you should be implementing is:

if YourVar = 88888888888 then
// Called from your other UBE
else
// Running stand-alone
end

My 5c... (we don't have a smaller coin in AU ;-)