According to Codd and Date, there is no use for a RRN. And if you "normalize" your database there is no need for it. Every record should be unique, though often in transaction files uniqueness is only achieved through a timestamp or sequential numbering. Position in the file is completely foreign concept in relational database architecture. IBMi still has it only as a legacy concept. It is totally fictional as there is no implicit ordering of records. The related concept of "arrival sequence" is also totally fictional, maintained only for legacy reasons.
Take a look at the JDBC specification documents. Particularly take a look at the contributors. You'll see folks on the committee from IBM and Oracle and the open-source community.
One of the reasons SQL is starting to drift all over the place is that there is no longer a demand for compliance to a standard. Up until 1996 or so, the federal government required NIST-certified compliance with SQL-92 standard. There's been one major revision of the standard published since then, SQL-1999, but the only big contributor to that standard was IBM (maybe I should say the main contributor) and they're the only ones that seem to have attempted to comply. There've been several expansions of the standard since then mostly to do with XML compantiblity and scripting languages. You can download the standards from ANSI (webstore.ansi.org). They want $30 to $285 dollars for each of the 14 sections.
The SQL standards have always allowed "extensions". RRN and arrival sequence have been included for DB2i as extensions. I don't think DB2 on other platforms support RRN; or at least not consistently.
JDBC, on the other hand, is completely driven by standards in the Java community. Contributors to JDBC standards committees have always included Microsoft, Oracle, IBM and the open-source community. It's mostly the lowest common denominator, but attempts have been made to bridge differences like TIMESTAMP vs DATE vs DATETIME, and so on which are different names for the same thing in various vendor implementations. Download JDBC 4.0 spec here:
http://download.oracle.com/otndocs/jcp/jdbc-4.0-fr-eval-oth-JSpec/ (Microsoft notably absent from contributors).
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of James H. H. Lampert
Sent: Monday, January 28, 2013 1:07 PM
To: Java Programming on and around the IBM i
Subject: Re: Hmm. "String nativeSQL(String sql) . . . converts the . . . JDBCSQL grammar into . . . the native form of the statement"
On 1/28/13 9:44 AM, Joe Sam Shirah wrote:
The nativeSQL() method asks the driver for the, um, native SQL
version of the statement submitted.
Uh, yes, that's what I said, and that's what the JavaDoc says. Which implies that there's a difference between "JDBC SQL grammar" and "native SQL grammar." But it's completely silent on what exactly "JDBC SQL grammar" is, and how it would differ from native grammars.
RRN is not an SQL concept.
Quite. And likewise, "LIMIT" appears to be a MySQL extension that a number of other systems adopted, while still others call it "TOP." All of this presumably because SQL standards appear to have been originally set to the lowest common denominator for every major database engine out there at the time. And may the Implementor of the Universe save us from database system architects who leave out something so seemingly obvious as RRNs (it's been a while, but I'm pretty sure that the classics, like ISAM and VSAM, have RRNs).
What, your Chinese guys don't know this?
Not their project, and they've got more than enough on their hands.
--
JHHL
--
This is the Java Programming on and around the IBM i (JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/java400-l.
midrange.com
