Hello All, I'm working with a library that is having problems running reports based on serials enumeration data, and I was hoping to get some feedback on an idea I have. Right now, we store the enumeration format in subscription.numberingmethod ( e.g. "Vol {X}, No {Y}, Issue {Z}" ). When the serial is received, the X, Y and Z are replaced with real values and this is stored in serials.serialseq and items.enumchron, I'm wondering if it would be better to store this data in separate columns instead. 1. Add columns x_description, y_description, and z_description to the table subscription. In the above example these would contain 'Vol', 'No', and 'Issue' respectively. 2. Add columns x_data, y_data and z_data to the table issues. So for "Vol 5, No 2, Issue 7", these columns would be 5, 2 and 7 respectively. 3. Retrospectively parse subscription.numberingmethod into x_description, y_description, and z_description 4. Retrospectively parse serials.serialseq into x_data, y_data and z_data At this point, we could get rid of serials.serialseq, or we could keep it alongside this new data. I would lean toward keeping it as we cannot guarantee step 4 will work right, as a librarian can modify serials.serialseq by hand when receiving the item. The question is: is this a good idea, or a stupid idea? Please let me know either way! Thanks, Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com )