Hi Frank,

Yes, it makes sense to me as long as the user cannot add another status type that you don't have any programming for. Might make sense to present them with the string value of status and they can name it whatever they want but it still correlates to the same underlying meaning. The code is still the same. This is a good way to use an enumeration to control your program execution as you can always reference a PolicyStatus.PENDING or PolicySatus.ISSUED anywhere. You can also setup properties that store it as that type and it is the only type that can be stored in the property. Or pass it around as parameters in methods and it is understood as a specific type.

public PolicyStatus CurrentPolicyStatus
{
     get { return this._currentPolicyStatus; }
     set { this._currentPolicyStatus = value; }
}
private PolicyStatus _currentPolicyStatus = PolicyStatus.PENDING;

Tim

>Tim,
>
>I think you may not be understanding fully what I am trying to do. Or maybe I am not understanding the point you are trying to make. So, I'll try to explain the full story.
>
>The system is an Insurance Administration system. Insurance Policies can move through various statuses. Initially it is tagged as "Pending", then it can go to either "In Force", "Withdrawn" or "Deferred". From "In Force" it can go to "Lapsed", "Matured", etc. I am controlling what status gets set in my code.
>
>As I don't want to force my status names on the end user (for example they may want "In Force" to actually be "Issued"), what I am doing is using a code in the background that the end user never sees, so "Pending" = 1, "In Force" = 2, and so on. So I created a Status table with the code and the Status Name/Description. The user will only ever see/edit the name (but they must understand that if they change "In Force" to "Matured" then things will look a little strange!)
>
>Now, in my code, rather than wanting to have to remember which status code corresponds with the "Withdrawn" status, I set up an enum which will return the correct code for me.
>
>I *think* this makes sense. :)
>
>>The purpose of enums is to provide a coding consistency and expose the options to components. Just like the example I gave you with mmSaveDataResult, how would you know what you could program to in code if Kevin had used a bunch of strings? Even if you created your enumeration based on what was in a table, how would you use that in code to make decisions? While it is possible to create a switch statement based on enums, how could you effectively code against unknown values?
>>
>>mmSaveDataResult only matters to the code and it is a situation where the programmer knew what he needed and how to use those variables. When you introduce values the user needs to enter and use and have meaning to, then it makes sense to make put them in a table. If you create enums that match and you program off of this, you should probably not let the users change those values or your code could be in jeoprady.
>>
>>Just stuff to think about it.
>>Tim
>>