>>>I had a chance to get away from computer and clear my head. Now that I re-read your message I understand what you are suggesting. But in my case, since I need about 300 flags, I would have to create 300 bit columns. And I don't like this idea. I will consider other options. Thank you.
>>
>>Have you considered creating a feature table with columns feature and present (true, false)?
>
>I did a while back. But this would require to move all these "features" into a separate table and treat them as a child table. I discounted it back then. But now that you remind me, I will reconsider this approach again and see how much refactoring it would take. Thank you for bring it up.

If normalizing, I'd go for first creating a feature_desc table

ID_feature (PK), Name, Description, FlagOrder (numeric seq candidate)

and experiment with Bills normalizing idea, but instead of column feature would use ID_feature for the data table.
Using the same description table you could test Fabios hint of Varchar(binary), using the order column to generate a function/memory data structure to allow quick mapping from varbinary string to vfp object of named flags and back. A single 250 VarBin column will give you 2000 flags, and you could concatenate a few such columns to a single string accessed into a couple of tenthousand flags with thr same structure of the feature desc table without the need to create a fpt - beyond hundredthousand flags a binary memo field is much better, but then the flag object and accesing it will be stressed ;-)

So if many more flags are needed, I'd argue to divide them into topics, give each topic a varBinary field and accompanying flag object, which can handle 2000 odd flags without strain.

Hope that is clear enough

thomas