At 12:31 AM 4/28/2000 -0400, Tom wrote:
>No it won't. It will Modulo the 2000427 by 10000 and go directly after
>427.
>
>What you have to avoid is using 64-bit E and R keys. If whole number
>values are used, you get a degenerate key where the whole base has one
>primary and everything else secondaries. The reason is that only the 1st
>32 bits are used for the hash and for whole numbers between 0 and 4mln,
>the 1st 32 bits are the same.

This is not quite correct.  Denys' previous explanation as to the hash
calculation for binary keys is basically correct.  And while Tom's explanation
as to real-type keys causing lots of secondaries may be correct, the
cause is actually slightly different than he describes.

IMAGE uses the 'right most' 32 bits if the size of the binary key field is
4 bytes or greater.  If the key field is 2 bytes, these bytes are placed in
the right 2 bytes of the calculation field and the left 2 bytes set to zero.
The reason whole numbers in real type key items greater than 4 bytes in size
(eg. E4, R4 or larger) generates lots of secondaries is because the mantisa
portion of the field (right most bytes) tends to be a consistent (zero) and
when used in the modulo calculation, derives the same address value.

Denys provided an excellent explanation of the calculation except for one
little detail, which given the number of years since he's been into the
bits-and-bytes of IMAGE, is clearly understandable.  And that is once the
right most 32 bits of the key value are placed in the 32-bit address for
the calculation, the sign bit is turned off if it is on.

There are a couple of other quirks that occur in the calculation when
the set capacity/hash capacity is greater than 65,535, or less then/equal to
65,535 with a relative address calculated result of 65,535 (16-bit value of
-1).
If one is not aware of these exceptions that are handled in IMAGE, it can
cause
problems deriving the proper address, regardless of key type.




>Shawn Gordon wrote:
> >
> > 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
X-no-Archive:yes

/jf
                               _\\///_
                              (' o-o ')
___________________________ooOo_( )_OOoo____________________________________

                          Thursday, April 20th

            Today in 1949 - Cortisone was discovered.

___________________________________Oooo_____________________________________
                             oooO  (    )
                            (    )  )  /
                             \  (   (_/
                              \_)