Bitwise check 'attributes record' in database

[Mike Dol]

Hi all,

I want to create rows in a table which id's are 1 - 2 -4 - 8 - 16 - 32 etc.

0000 0
0001 1
0010 2
0011 3
0100 4
0101 5
0110 6
0111 7
1000 8

So I want to use a Bit mask?

Since I'm a complete noob when it comes to bitwise comparison I want to know if I can use this to accomplish what I want.

I have a table e.g. Table A with food items (steak, tuna, meat balls, etc) and I want a table B (with child records in table C) with attributes which I can add to the food items in Table A.

For instance I want to have a record "TEMPERATURE" in table B. This record has child records "MEDIUM - RARE - WELL DONE".

Another record "SAUCE" has "WHISKEY - MUSHROOM - BLUE CHEESE - ETC"

And "SIDE ORDERS" has "BAKED POTATOES - FRENCHFRIES - ETC"

In the main table A with food items I want an integer field which values are built depending on the records in Table B which are relevant for the product.

If you can still follow me, steak for instance needs to have TEMPERATURE, SAUCE & SIDE ORDERS as attributes and Meat Balls only needs SAUCE & SIDE ORDERS.

I want to fill the Bitwise ID field in the RowOrdersUpdatedEventHandler, if it's value is 32 for instance, how do I change it to the next ^2 value?

Am I limited to let's say a maximum of 32 items if I want to solve this bitwise or is there a better way to do this?

Any help is much appreciated!

Best regards,
Mike

[Killer42]

What version of VB are you using?
What do you mean about going to the next power of 2? To go from 32 to 64, you just multiply by two.
To allow more bits, you should be able to use Long instead of Integer.
As to whether it's good or bad, I guess that's largely subjective. If it works, it works. One alternative might be to use a string/text field with characters rather than bits. Less compact, but perhaps simpler to work with.

[Mike Dol]

What version of VB are you using?
What do you mean about going to the next power of 2? To go from 32 to 64, you just multiply by two.
To allow more bits, you should be able to use Long instead of Integer.
As to whether it's good or bad, I guess that's largely subjective. If it works, it works. One alternative might be to use a string/text field with characters rather than bits. Less compact, but perhaps simpler to work with.

Sorry for the delay, I use VS2005. I decided to use a parent / child table to solve this problem, I'll try the bitwise solution next time when there are not that many combinations needed.
You were absolutely right I just had to double the integer / long rowID got to keep my thinking straight...

Thanks for your help!

Mike

[Killer42]

Sorry for the delay, I use VS2005. I decided to use a parent / child table to solve this problem, I'll try the bitwise solution next time when there are not that many combinations needed.
You were absolutely right I just had to double the integer / long rowID got to keep my thinking straight...

Thanks for your help!

Oh well, glad to hear you got things working, anyway. :)