I'll add my own opinion that "Rec Type" is not the best place to keep records about whether a member is "active".
I'll also add a little explanation about one way this could be detected. "Rec Type" is a single-valued field. With values like "bus", "ind", "org", "fdn" the code set implies that a record should fall into one and only one of these categories. This is a nice, cleanly constructed piece of data - a single valued field is used to store an information item that can only take a single value. In addition, the values assumed by the field all seem to convey a similar type of information. This is a nicely constructed field, and it will be easy to use and manage. The use of "rec type" to store values like "gets daily newsletter", "gets weekly newsletter", "gets mothly newsletter" etc. disrupt this nice clean structure, because it is conceivable that a record could represent BOTH a "business" AND someone that "gets daily newsletter". The fact that the resulting code values are no longer mutually exclusive is a tip-off that this field isn't the best place to enter those "newsletter" codes. It's typically desirable that different types of information should be stored in different fields. In addition, a single-valued field doesn't handle two types of different well unless you use a value list that contains all possible combinations of the two sets of codes. And that can get out of hand quickly. For instance, in the example above, 12 values are required to cover all possible combinations of four "record types" and 3 "newsletter subscription" types. If newsletter subscriptions were handled 5 different ways, it would take 20 different values in the code list to handle all possible combinations... A field which can be deconstructed into more than one type of information is sometimes called an "overloaded field". It is a general good data management practice to avoid using overloaded fields. For the most part, it works out best to have one field contain only one type of information, and the field name should be evocative of the information contained. ------------------ Reminder to each recipient: To change your list account preferences, go to http://email.sparklist.com/scripts/lyris.pl?enter=support and enter the email address you used to subscribe to the ebase support list:: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] --------------------------------------------------------------------- ebase - Relationship Management for Nonprofits, http://www.ebase.org ---------------------------------------------------------------------
