Just for consideration, I wanted to offer a clarification to part of Carl's reply...
Certainly, I agree that you shouldn't change the names of EXISTING Ebase fields. But if the existing Ebase contact fields don't correctly describe the information you need to maintain, I think it can make a lot of sense to create NEW fields which more clearly label the information that your organization wants to track... In that case, the "contact flag" check box labels that you change should be evocative of any NEWLY CREATED field that they display. It can sometimes become pretty confusing when a field on a layout is labelled "fax broadcast" and the field it is actually connected to is named "contact phone". This leads to a circumstance where a field's name actually doesn't indicate the information contents correctly. I feel that one of the highest priority rules for data management is "use evocative labels for field/database names". In the long run, it can be a big help when the name is actually evocative of the information contents. Database work often becomes very difficult when field names don't actually reflect data contents of those fields... Although this "clarity of labelling" issue may seem obvious, I've found poor field/file names to be one of the most pervasive data management problems. And the consequences can be significant in terms of the increased expense and trouble for maintenance of your data... ------------------ 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 ---------------------------------------------------------------------
