John,
Perhaps part of the problem is that you are attempting to use the value generated by IHASH as if it is a unique value. By definition, the IHASH formula does not guarantee a unique integer. Think of the huge number of possible unique values for a text string, with 26 x 26 x 26 ... possible combinations. Translating that into an integer, where you have only 10 x 10 x 10 ... possible values (depending on number of characters), should illustrate that sooner or later, two strings similar or not, could generate the same integer. In just 2 characters, there are 7 times as many values as can be stored in a two-digit integer.
The best uses for IHASH are for a very crude, low-level kind of encryption, and for generation of a faster result for very large data sets.
For example, I never store a password in the database as plain text. I always store the IHASH value of the password. That way, if somebody happens to see the IHASH value, they can't "log in" as that person, because they would have to first figure out what string generates that IHASH value. It's a crude encryption, because it wouldn't take long to write a program that would loop until it generated a string that matched the known IHASH value. It works to stop the idle, curious employee with few scruples from explorer where he or she shouldn't. It's not much of a barrier to the determined and professional hacker or theif.
Queries of integers are somewhat faster than queries of text strings. (They used to be WAY faster.) In the past, when we stored the IHASH value of a long string to speed retrieval, we did a lookup like this, with a compound condition looking for BOTH the hash and the value:
DIALOG 'part name:' vPartname vendkey 1 SET VAR vHashName = (ihash(.vpartname,0))
SELECT * FROM tablename WHERE hashcolumn = .vhashname AND partname = .vpartname.
Bill;
John Docherty wrote:
Razzak,
Well if you think it would help, yes - as Albert has suggested there may be
a better way to do what I am doing, which is just really looking up a table
to match values.
The IHASH command was working fine until I added the longer strings and then
I spent some time trying to work out why my lookups returned the wrong
descriptions. It took a while to sort out the reason for this as I expected
that IHASH would work OK with numbers in the text (which it did with all the
other entries in my table), but obviously the algorithm must have some limit
as far as returning unique integers with long strings - maybe this should be
mentioned in the Help entry. The RHASH function would no doubt increase the
'limit' on string lengths - but I will leave the decision on that up to the
good people at RBTI.
Thanks for looking at the 'problem'.
Regards,
John Docherty
-----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of A. Razzak Memon Sent: Tuesday, 22 February 2005 11:54 a.m. To: RBG7-L Mailing List Subject: [RBG7-L] - Re: IHASH Command
At 05:23 PM 2/21/2005, John Docherty wrote:
Thanks for that, but I note that if I reduce the length of the text (including the three 'numeric' characters at the start) I get different values from the Hash command. Does IHASH need an alternative function RHASH (a real value) to cater for longer strings?
So, you want us to add a new function for you. Right?
Very Best R:egards,
Razzak.
