Hi

On Fri, 29 Oct 2004 00:58:42 +1000, Ken Galbraith <keng@...>
wrote:

FWIW I am not currently a FB user - though I am contemplating the change :D

Converting to chr(1) to enable Y/N T/F is (IMHO) only for more
compatibility with "other" db's. Personally I see nothing to be gained in
such a conversion. As you are already VERY familiar with the "coding
practices" to save, store and compare YOUR "flags" and no doubt have the
reasons to use them, I suggest you continue with your method.

I guess you could (in the 32 bit world) use an INT (meaning what is now a
16 bit INT) for your 15 flags. For convenience it is MUCH easier to do a
logical comparison against ONE field for up to 15 flags than to step
through FIFTEEN fields to achieve the same result.

While CPU speed, ram and disk space obviate the NEED to do this for
"storage" reasons, the logical (as in arithmetic logic) is just as VALID
NOW as before.

I am sure for you, that at would be less work converting your legacy code
into a suitable FB "TYPE" than to rewrite your code to add and work with
numerous chr(1) fields. For "NEW" programmers maybe things are different.

BTW I think you will find that the comparison of a Y/N or T/F field will
still be a boolean comparison (within code) ie a bit comparison not a
character "value" comparison.

> In my legacy CB86 application, I store up to 15 Boolean flags (Y/N) type
> fields in a small integer (16 bit) fields).
>
> I am converting this to C++Builder/Firebird & am seeking the best way to
> represent these flags (0/1, Y/N, True/False etc ) under a Firebird
> regime.
>
> Coming from the old school (I am 57 and started programming in 1967) I
> have
> used signed integers (16 bit) to store up to 15 separate fields, using
> functions to set/get individual flags based on 2^n etc.
>
> I have been told by the experts in FB (Helen B for example) that I should
> convert these values to chr(1) ie Y/N or T/F etc & while I am as aware as
> any of you that CPU processor speed, HDD capacity etc, rave, rave ra ,ra
> have eliminated the old problems of 64 kb memory space & 5 Mb HDD space,
> I
> find it very hard to not try to keep disk storage & bytes transferred
> across
> the network to a minimum.
>
> Firebird doesn't have a Boolean data type. This doesn't concern me as I
> want
> to use what FB has.
>
> The question I am really asking is:
>
> Should I use Integer/Big Int & concatenate my Boolean fields, or should I
> convert them to char(1) values of "y"/"n" etc or smallint values of 0/1.
>
> PS: In my application I have as many as 30 of these binary fields
> ( which is
> why I am inclined [ unless otherwise convinced ] to use int or small int
> fields & use Boolean functions to split them up).
>
> PPS: As an assembler programmer from way back (1968) I am well aware that
> Boolean logic is shorter & much faster than string (or even single
> character ) logic.
>
> There must be some of you out there that have converted legacy
> applications
> to ones using a modern RDBMS such as FB who have gone thru' this process!

--
Kind regards

Peter Sanders