RE: Hmm. Now how to get the data from the JDBC connection into a form we can use . . .

James,

I think you should take a look at the RPG Open (Open RPG?) interface Vern Hamberg published. He was working with ODBC drivers instead of JDBC drivers, but he faced the same challenges. He directly implemented CHAIN, SETLL/READE, SETGT/READPE and all the other record level access methods of RPG using SQL.

JDBC is an interface specification. As such it is designed such that the Java user will get the same results using any driver against any database. All the variations in data storage and other anomalies are hidden by the driver. The contract is at the interface level. ResultSet.getBytes() bypasses that contract. It promises to return the "raw values returned by the driver". Notice that there's no contract to return the raw values as contained in the database, only to return the raw values from the driver. Drivers can vary widely in how they handle the network interface with the database and the network interface varies widely on how it handles the character stream. JT400 uses DRDA to communicate with DB2 for IBMi while the drivers for SQL Server use tds (http://en.wikipedia.org/wiki/Tabular_Data_Stream). MySQL has its own network interface.

I think what you're trying to do, make a universal database attachment for RPG, should rely on the obscured interface without digging down into the individual drivers.

-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-
bounces@xxxxxxxxxxxx] On Behalf Of James H. H. Lampert
Sent: Wednesday, July 10, 2013 6:04 PM
To: 'Java Programming on and around the IBM i'
Subject: Hmm. Now how to get the data from the JDBC connection into a
form we can use . . .

Some thoughts and musings. Comments from the peanut gallery would be
welcome.

One thought I had was to expose and wrap the remaining ResultSet.getxxxx
methods that weren't already exposed in JDBCR4.

Then I noticed the ResultSet.getBytes() method: running an actual Java
program calling JDBC on DB2/400, I get the correct raw bytes for both
zoned and packed (and the raw bytes for character fields even come up as
EBCDIC.

Then I realized that the method wouldn't necessarily produce anything
directly usable for databases other than DB2/400. And to that end, I
replicated our familiar VIEWCUS PF in MySQL. Damn: for both "Numeric"
and "Decimal" fields, getBytes on a MySQL database yields ASCII digits,
with leading zeros truncated off, and actual ASCII minus signs and/or
decimal points among the digits.

Interesting: getObject() on a Numeric field that doesn't have any
decimal places yields an Integer, but on a Decimal field with no decimal
places, it yields a BigDecimal.

Given that I haven't a clue how to deal with a BigDecimal in ILE or OPM
RPG, much less in OPM MI, I'm thinking that the simplest solution for
the problem at hand is to get everything as a string, and convert it
into whatever form it SHOULD be in.

But it also looks like JDBCR4, so far, has not exposed any of the
methods for updating through a result set.

--
JHHL
--