First, there's BIN_AND function in Firebird, so you can write
BIN_AND(FLAGS, 2) and it's the same as bitwise "FLAGS AND 2".
But packing bits into integers, while saving space, is somewhat
cumbersome (so if DB size is not your primary concern, reconsider).
Besides, if in the future your 26 flags become 126 flags, you may run
out of bits in your ints (and you'll need to introduce another field, as
a continuation of the existing one, all queries get complicated etc.),
while altering CHAR(26) to CHAR(126) is easy.
I personally express flag fields as char fields consisting of 'Y's and
'N's, e.g. 'YYYYNNY'. Then you can filter by that field using LIKE, for
example: SELECT ... FROM ... WHERE BIT_FIELD LIKE '__Y_Y_N' (_ in LIKE
stands for "any single character"), which gives all rows with BIT_FIELD
containing "Y" at positions 3 and 5 and N at position 7 (all other
positions are irrelevant). I know such fields take more space than
"bit-packed" ints, but their processing is simpler and they are human
readable (you can easily modify such data with a sql tool).
Setting a flag at a given position (bit_pos) can be achieved via a
statement like this: UPDATE ... set BIT_FIELD = substring(BIT_FIELD from
1 for bit_pos-1) || 'Y' || substring(BIT_FIELD from bit_pos + 1).
Using LIKE probably prevents FB from taking advantage of indices, but so
I'm not saying that's the best possible solution, but it's worked for me
just fine, so just a suggestion ;)
Ta wiadomość zawiera poufne informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę, prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.