>>>>If I store a number of power of 2 into INT field, how many different "values" will this field hold? I am not sure I phrase my question correctly, so here is an example of what I am trying to say.
>>>>Say I store 128 into a INT field. Which means that I can get 7 numbers: 2, 4, 8, 16, 32, 64, 128
>>>>Since an INT field can hold up to 2,147,483,647, what is the max number can I get from this value?
>>>
>>>The maximum value in regards to that calculation would be 1,073,741,824. That would be 2^30. If you go higher, you will be one number over the maximum. I would suggest to switch the field to Big Integer if you have some concerns.
>>
>>This is about 1 billion. For what I am trying to do, this is more than enough. Thank you.
>
>
>Still somewhat puzzled by your question ;-)
>
>One possible use for a int in power2 is in "combination mode" as array of bit fields most of us remember.
>Yes, you can easily squeeze 30 flags into an INT, but why ? SQL server has the bit data type and will pack on byte sizes depending on the number of flag[s / columns] you need. Say you need 15 flags, SQL Server will only reserve 2 bytes. Small benefit size ways but NO DANGER if suddelny you need 33 flags....
>
>OTOH, if there the max value which is important after differing # of iterations, I'd save the exponents and work directly with them, perhaps with dedicated functions or SPs.
>
>Indexing on such fields probably problematic IAC. What am I missing ?
>
>Friday curios
>
>Thomas

This does remind me of the seemingly odd restriction that occurred in the implementation of the Pascal language on Control Data mainframes. This involved the implantation of sets. You couldn't create a set of char, but you can declare a set of a subrange of char. The system used 6-bit bytes and 10-byte words. 6-bits could represent different 64 values (0-63), but a word only had 60 bits -- so you couldn't assign a bit for each of the characters.

I am also reminded of an old "hack" that could be used to store 10-digit phone number in just 4 bytes (assuming you were only dealing with phone numbers in the USA) -- which unfortunately ended getting "broken" in the mid-1990s. The idea was based on the fact that middle digit of the area code (the first three digits of 10-digit phone number) was generally only a 0 or 1. By swapping the first two digits, you ended up with a 10-digit number that was less than 2,000,000,000 -- which is less than 2,147,483,647 (maximum positive value that could be stored in a signed 32-bit long integer). 4 bytes is 1 byte less than the 5 bytes you'd get if you tried packing using BCD format - which of course is half as many bytes you'd have if you stored the number as character values. By the mid 1990s new area codes were introduced with digit values 2 and greater, causing this "hack" to break..