Well, that was incorrect.

For a numeric key (type I, J, K, or R), Image uses the rightmost 32 bit, drops
the sign if any, subtracts one,  sets it to itself modulo the capacity of the
dataset and then adds 1.  This will yields a primary address value between 1
and capacity.   Given a capacity of 10,000 and a key value of 2,000,427, Image
will definitely not loop around.  Instead it will produce 427 as the primary
value according to the formula above.

For a non-numeric key (type X, U, P or Z), things are slightly different at
first.  The key is hashed to produce a 32 bit positive random value.  The
hashing involves using the key value 32 bits at a time and doing bit shifting
and adding to get a value that can be reproduced given the same key value.
 This value is then put through the same steps as detailed above.

As for speed.  It depends.  Numeric keys, if used properly, are extremely fast
in DBPUTs and DBGETs.  If you set up the capacity and the key values in a way
that assures there are no secondaries, you will have a one to one relationship.
 If you screw up, the numeric key setup will kill your application.  There have
been many articles written on the subject over the years.  Fred W. has written
some excellent papers on this issue as have others, including yours truly.

If your key values are random and not under your control, then you should use
non-numeric keys which will be managed by Image and thus assure you of a good
spread across the database, with some secondaries.

Kind regards,

Denys. . .

Denys Beauchemin
HICOMP
(800) 323-8863  (281) 288-7438         Fax: (281) 355-6879
denys at hicomp.com                             www.hicomp.com


-----Original Message-----
From:   Shawn Gordon [SMTP:[log in to unmask]]
Sent:   Thursday, April 27, 2000 4:47 PM
To:     [log in to unmask]
Subject:        Re: Image hashing.

An I doesn't hash, which is why it's faster, it goes to the physical
location represented by the value.  If you control them and sequentially
assign them, then it is fast, however... If you are using date as an
integer key for example and have a capacity of 10,000 and a value of
2000427 in the key field, then image is going to loop around until it
counts up to 2,000,427.

You are typically better off with an X

At 03:23 PM 4/27/2000 -0600, Timothy Hoefner wrote:
>I'm going at it again with our DBA but I can swear that I learned
>somewhere that TurboImage can hash faster with an X item
>rather than an I item.
>
>I hope I made sense.  Thanks again.
>
>
>Timothy J. Hoefner
>[log in to unmask]
>(915) 831-6144