Re: Another JDBC (and by extension, JDBCR4) meta-data retrieval question

On 05 Apr 2013 11:44, John Yeung wrote:

On Fri, Apr 5, 2013 at 2:26 PM, CRPence wrote:

I presume the /displayed/ results are giving a false impression.
What interface was being used to draw that conclusion was unstated,
but presumably it was likely either a Display File or the Query/400
report writer; DFU as I recall, does not have support for Float.

You're right. I happened to be using Query/400.

Depending on the interface used to /display/ the effects of the
specification, the results can change; i.e. not all interfaces
will present the human-readable form of the floating point
representation with the specified number of decimal digits and
decimal digits after the decimal point.

Yeah. Query/400 happens to honor the preference, in its way.

The Specify Report Column Formatting allows overriding the preference specified in the DDS; i.e. making its effective /edited/ presentation different than what was specified in the DDS.

I see that DBU also tries to, in its way; which happens to make
manual entry of many valid values impossible.

I know almost nothing of DBU, but there should be no reason that particular utility would have to or even should prevent entering any valid floating point value [double or single, according to the Floating Point Precision] irrespective of the presentation of the current value... just like a display file. That is, the data being passed from the EUI to the file should be the actual IEEE binary representation as generated from the human-readable form that was specified by the user.

So float-handling is kind of a crap shoot.

Perhaps as inferred from what is presented, but the actual floating point value is both stored and known-to\understood-by the system, regardless of the means used for presentation. The only issue I have had with floating point is the inaccuracy for attempts to represent decimal arithmetic.

This is further disincentive, in my book, to defining float fields
on the i, particularly in DDS. (The main disincentive being the
counterintuitive (to most people) and often undesired arithmetic
behavior.)

I have always avoided any use of Float since learning about it in college. I have never had any need for anything other than decimal calculations. The few times I have _had to_ deal with floating point was either to obtain data from another database\platform, but mostly to ensure that the FLOAT functioned according to the design for the Query/400 report writer; in either case, the inputs and updates were all via SQL, and the internal storage verified with DSPPFM or CPYF when necessary.