>
>I'd argue long and hard for the use of an enum in this sort of thing: convert to an enum as soon as the table value (int,byte whatever) is retrieved and only convert back when the value needs to be committed to the backend. No magic number or casting required (or allowed) *anywhere* outside the layer closest to the DB.
>Using an enum certainly doesn't make things any more 'fragile' - any alternative scenario (constants, etc) is more open to that accusation. And if you have a 'flags' enum type requirement then multiple the benefits of enums by 10......
>
>But I can't argue now - work to do :-{

Hmmm, well I was trying to not judge his choices. I would only think if the data is table driven and you then had a matching enum for other comparrison reasons, the application would be broke as soon as somebody added a value to the table. If the enum is the only data driving the choices then I agree so long as those choices are static like "Male versus Female" or "Mrs, Mr, etc". No argument here, we are probably on the same page.
Tim