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

On 04 Apr 2013 16:45, James H. H. Lampert wrote:

Given a test PF defined in good-old-fashioned DDS as follows (extra
spaces squeezed out):
A UNIQUE
A R TEST04AP13
A PACKED 5P 0
A FLOAT1 7F 0
A DOUBLEFLT1 15F 0 FLTPCN(*DOUBLE)
A FLOAT2 7F 2
A DOUBLEFLT2 15F 7 FLTPCN(*DOUBLE)
A FLOAT3 7F 6
A DOUBLEFLT3 15F14 FLTPCN(*DOUBLE)
A K PACKED

Notice that the floating point fields have "preferred" number of
decimal places defined.

If I get the meta-data the old-fashioned way, via the system APIs,
then I can get the preferred number of decimal places, and QuestView
pays attention to that, and displays them thusly:
PACKED . . . : 12345
FLOAT1 . . . : 1234500.E-002
DOUBLEFLT1 . : 123456789000000.E-005
FLOAT2 . . . : 12345.00E+000
DOUBLEFLT2 . : 12345678.9000000E+002
FLOAT3 . . . : 1.234500E+004
DOUBLEFLT3 . : 1.23456789000000E+009

But if I get the meta-data through a JDBC connection, then
getScale() always returns zero, meaning that I have to arbitrarily
decide the preferred number of decimal places to show.

Unless there's another way of getting that value via JDBC?
<<SNIP>>

Best I can recall, the numeric scale for FLOAT is considered by the *DBXREF [and thus by the direction of the SQL] to be the equivalent of numeric /editing/ which is not in the realm of the SQL. Thus the value for the column DBINSC in QADBIFLD is always the NULL value whenever the value of the DBIITP is 'F' for which the value of DBITYP is 'FLOAT'.

And just like with numeric editing being honored, the Query/400 report writer will honor the precision\scale specifications on the FLOAT data type columns for its report presentation. Thus testing with STRSQL [for local connections which use the Query/400 report writer for output] will show the /edited/ floating point representation, just as it does for an /edited/ numeric representation.

The JDBC can get access to the "the preferred number of decimal places" by obtaining "the meta-data the old-fashioned way, via the system APIs" just as is noted the QuestView does. The JDBC could easily retrieve that data via a UDTF or a stored procedure, that would return the necessary information in a result set.