>Hi Viv
>
>>No - Varbinary is just an array of bytes.
>
>OK, thanks for the explanation.
>
>
>>Worse yet. From BITTEST help: 'If the specified expression is not an integer, it is converted to an integer before performing the operation' so I was wrong about being able to use 52 bits, - looks like 31 is the limit. Could you divide the modules into logical groups of 31 or less and use a int for each group?
>
>Wow, that sure is limiting from my point of usage.
>
>
>>Or maybe you'd be better served just using a lookup table?
>
>Now that is an idea, I could probably use encrypted records. Thanks I will think on this line.

Actually you can use strings bitwise - just mark them as NoCpTrans, i.e. binary. You can chop the strings to characters, and then set individual bits of those characters. You can imagine each string as an array of bits, n by 8. The only trouble is that your bytes would be starting off with 1, while bits would start with 0 and go to 7.

So, getbit(c, n) would require to chop n into bit number (nBit=n%8) and the byte number (nByte=int(n/8)+1)... like this:

procedure getbit(c, n)
nBit=n%8
nByte=int(n/8)+1
lcChar=substr(c, nByte,1)
return bittest(asc(lcChar), nBit)

procedure setbit(c, n)
nBit=n%8
nByte=int(n/8)+1
lcChar=substr(c, nByte,1)
lcNewChar=chr(bitset(asc(lcChar), nBit))
return stuff(c, nbyte, 1, lcNewChar)

Untested, but shouldn't be far. For a 10 char string, you'd have a 80 bit field. Actually, you could even have a binary memo where you could control the positioning of each bit. As long as you initialize the whole string with replicate(chr(0), n) you should be fine, and memo shouldn't even bloat.