New York State Archives would like to be able for increased field sizes, especially for custom fields, so that they can record multiple container barcodes within one request record. This is because one request might require the retrieval of multiple containers from the same series. Cloning such requests repeatedly, simply to accommodate the number of containers being requested could get very cumbersome for our staff. It is easier to use just one request record and record all of the barcodes there.

Boston Public Library would like for custom fields to have more than 255 characters. They are developing a conservation workflow, and would like to use Aeon to record conservation needs and outcomes, which often exceed the character limit.

Georgia Archives asked that the ItemPages field be increased - they have run out of space with some complex patron requests.

Georgia Archives asked that the mailing address fields be increased and/or additional mailing address lines be added.They work with many government agencies, and mailing addresses are typically comprised of several long lines that include contact name (different from the requesting patron), building, office, department, etc.

The University of Arkansas and Case Western asked that the Title field be increased. It is currently limited to 255 characters and displays a confusing message when the title exceeds the character limit. Case Western noted that many of their collections have very long titles.

The University of Arkansas would like the custom dropdown feature for Transactions on the client side. They are using one of the ItemInfo fields to record delivery stop location codes for CaiaSoft. A controlled vocabulary would prevent typos.

<happy dance> :-)

Most sites require patrons to fill out the State field. The State dropdown includes an N/A option. Aeon should include an additional database field for Province/State for international researchers. If possible, this field should be conditional and only appear if the N/A option is selected from the State dropdown.

Hi, along these lines, one of our archivists, Mark Custer, told me it would be possible for our IT staff to add additional fields to the Aeon database. Has anyone ever done this?

One of the things we ran into when using the shared user database is that each library wanted to track a similar field, but could end up having totally different values for each user, so we needed to move these to UserInfo fields. For example - Status. The 3 libraries wanted to track this separately, it ends up using the the main status field and 2 of the 5 UserInfo fields, so they were used up fast. We ended up having to use a plugin to save the info to a different table, but then the data was not searchable within the Client. Other items that we've been trying to track are "How did you hear about us" "Purpose of today's visit" etc.

I agree with Moira that the Transactions table is just as critical. We're quickly running out of usable fields there, and we've also juggled things around because the default field lengths don't allow us to save the data we need, especially with regards to duplication.

One piece of information we'd like to store is fellowship information, since one of the reports I have to run is on how many of our reading room visitors are on a fellowship. We use UserInfo3 to record that. Our Manuscripts & Archives repository uses UserInfo1 and UserInfo2 to record information about permissions that researchers have to view special collections. One way to approach it might be to have more "user defined" fields, since it will be hard to predict what everyone would want. As we add more reading rooms at Yale we're seeing that everyone has information they'd like to track and we're running out of fields to use, and yet there are some fields that we just don't need. Also, as we work with different campus systems, I could imagine possibilities where we could import things like student majors/programs, class year, graduate vs. undergraduate, etc.

For us the transactions table is more critical. Again as we add more reading rooms we're finding that different pieces of information stored in the MARC record or finding aid that are critical for paging or things we would want to run reports on. Examples include restrictions, notes fields that include size and locations, etc. Again we're running low on iteminfo fields, so having more of those would help, while fields like ISXN and MaxCost just aren't relevent. I think the recently released SAA-RBMS guidelines could also be consulted, as they recommend some standard pieces of information.

Perhaps as this discussion thread continues, a conversation could also be held at the XPSU conference next month?

Thanks!!!

Can you give examples of what kinds of fields you are storing? We are trying to decide what fields would be best to add.

I can't tell you how much this would have made our life easier during our implementation phase. This was actually promised during investigation, but it never materialized.

We implemented a shared user database across three sites here on campus, and we all had more information than could be stored in the available fields. We ended up using a plugin to store the info, but it hasn't been very satisfactory.

Hi. We currently use one of the UserInfo fields to record fellowship information, as we have to report how many of our readers each year were on a fellowship from our library. Other sites on campus use UserInfo2 and UserInfo4 to record if patrons have permissions to view certain collections. I could see the benefit to having dedicated fields for those purposes, as opposed to fields for fax number, date of birth, or even delivery method. Thanks.

Hi,

Are there any plans to modify or add fields in the Aeon database?. Many of the fields seem to be copied over from ILLiad, like MaxCost in the transactions table, which I can’t imagine many special collections places would use. Or just outdated, like fax in the users table. I ask this because we would like to import more information from our catalog records into Aeon, and we are already running low on iteminfo fields. It seems like it would be a good idea to review those fields with the user community to see what people need.

Thanks!

Moira

How many fields are necessary and for what purpose?

Would like to have more data fields to store information and for the data type to be specified (date, money, text, note, etc.)

Sites would like to have more drop down fields on the request form that they can control the possible values.

- Don't want additional notes filtering (because don't want to user the notes table)
- would like at least 3 fields to be used by staff for lengthy notes that could be printed
Don't want visible to researcher/requestor.