Besides proprietary utilization, what's the purpose of alphanumeric
uniqueness, especially in the example given? If the first and last
characters never change, the uniqueness is flawed by design. The
logarithm depends on a limit of 3 characters and 2 digits (which equals
100 possible combinations).
Now my statistical and probability math is a little rusty, but doesn't
that equal 26 * 26 * 26 * 100 which is 1,757,600 possibilities? That's
fine if the database in question is of a low production and uniqueness
will be another programmer's problem. :) HOWEVER, since numeric
searches and relationships are inherently more efficient than alpha
searches and relationships, wouldn't it make more sense in the long run
to convert the uniqueness to something more quantifiable and extensible?
Let's work with the 7 character parameters in play, with only 5 of them
presenting unique properties. The 7 character field as defined produces
1,757,600 possibilities before uniqueness is compromised. A 7 digit
numeric field produces 10,000,000. Granted, a true 5 character
alpha-numeric field (36 * 36 * 36 * 36 * 36, assuming no special
characters or spaces) produces 60,466,176 combinations which is
substantially higher than the 100,000 available to a 5 digit numeric
field, but unless the character field in question is declared as
varchar, the database uses the same space for each character field.
Now let's extend the database beyond RPG and native access (I know, you
purist will call be a blasphemer) into the realm of ODBC, JDBC, OLEDB,
etc. Although native data types are very efficient in a native
environment, they are historically slower when reliant upon driver
conversions. If you think embedded SQL is slow, you should see the I/O
required on both sides to translate native data types to driver specific
data types.
Tom Armbruster
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Thursday, May 22, 2008 5:25 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Increment an alpha field by "1"
What you say is true, though I'd add that you can do the same thing in
RPG just by overlaying a 1A field with a 3U 0 field in a data structure.
The problem with your approach, Vern (you knew this was coming, right?)
is that EBCDIC letters aren't always contiguous. It's true that if you
had A (EBCDIC 193) and you added 1, you'd get B (EBCDIC 194). However,
if you had the letter I (EBCDIC 201) and you wanted to get J, you'd have
to add 8 since J is EBCDIC 208. IMHO, it's easier to use an array when
you increment instead of trying to use the numeric value of the letter.
I suppose you could convert you letter to Unicode (RPG's "C" data type)
and add 1 there. Unicode letters are all contiguous, so that'd work
better.. but it still seems like a lot of screwing around.
vhamberg@xxxxxxxxxxx wrote:
Do it in C - that does this kind of increment nicely, since it treats
characters as 1-byte integers, sort or - Scott will probably have to
correct me!! But you'd still want to separate the 2 sections, numeric
and alpha, and check ranges and overflows.
Actually I'm not kidding!! ;-)
midrange.com
