RRN is probably not a good entity to use for database development. It is a crutch in the Iseries world that probably should not be used. It is probably as useful [to an iseries developer] as knowing the drive sector that a record currently resides on.
It fails as an identifier of a row, mainly because it is not immutable - ie it can and does change for a given row.
So ages ago high-quality database designers set up a simple immutable key structure with an auto-incrementing sequential immutable key. Unfortunately DDS has never provided this, so Iseries developers try to make up their own. Often they tie the sequential key to an item#, customer#, invoice#, etc.
That is when things start sliding downhill.
I think that all the better database engines out there today provide a simple mechanism to create an immutable auto-incrementing key for each record. Even the JDE type toolsets provide this.
Iseries only provides it when creating files with SQL, which is probably a small percentage of files in the iseries world.
So, on other platforms, RRN just gets people in trouble and database designers [outside the iseries world] most likely frown upon its use and try to hide it from developers.
My 2 cents anyways.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James H. H. Lampert
Sent: Monday, January 28, 2013 11:01 AM
To: Midrange Systems Technical Discussion
Subject: Re: Uniquely identifying a record in SQL without a unique key?
On 1/4/13 1:17 AM, Dave wrote:
Keep going James, you are doing some good work and we are all getting the
benefit!
Hmm.
At this point, I know that (at least in MySQL, which has no concept of
RRNs; hopefully I'll know about DB2/400 later this week) you literally
are not allowed to obtain an update cursor on a file that lacks a
primary key. (You ask for an updateable result set, and it gives you a
read-only one anyway).
And it turned out that the tutorial Mark recommended *did* mention that
you needed a primary key to get through the update-by-result-set
example. But that remark was so inconspicuous that I didn't even find it
until after I'd already come to that conclusion, and had spent over an
hour trying to find out how to set one up. (You'd think that if a
primary key were that important, the JDBC tutorial would have included
it in the environment set-up section, and both the MySQL docs and the
Sequel Pro helptext would make a point of telling you how to set one up,
as well.)
This morning, I went into MySQL again, with Sequel Pro, and created a
"multiple identical records" situation, then tried to change one through
Sequel Pro. Unlike my previous test with Squirrel on DB2/400, I was
actually able to change exactly one out of three identical records, and
when I looked at the underlying requests in the console, I found that it
had done an UPDATE request with WHERE clause on every field in the
record (much the same as Squirrel had done), but also added a "LIMIT 1"
clause.
Further research tells me that LIMIT is not standard SQL, any more than
RRN is.
Ye vish!
--
JHHL
midrange.com
