Database fields - bigger, better, more flexible
There have been multiple situations that our life would have been made much easier if we had more flexibility in the Aeon database fields. For example, it is often suggested to use "another unused field" to store data. We often run into the issue that these fields are character limited.
The max length of any text field seems to 255 characters, which can be totally impractical for some purposes. I am assuming that this might be because of the MS Word mail merge character limit?
Is there any reason why text fields could not not be expanded to something like 1024 characters?
"Note" fields at the User & Transaction level: Having the notes grid is useful, but sometimes you just need a big block of text at User or Transaction level that is not in a related table.
Custom dropdowns in the Users, Transactions, and Activities interfaces
Aeon 5.1 added the unlimited custom fields feature but did not increase field sizes.
-
Anne Marie Lyons commented
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.
-
Anne Marie Lyons commented
Georgia Archives asked that the ItemPages field be increased - they have run out of space with some complex patron requests.
-
Anne Marie Lyons commented
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.
-
Anne Marie Lyons commented
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.
-
Anne Marie Lyons commented
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.
-
Matthew Adair commented
<happy dance> :-)
-
AdminKatie Gillespie (Special Collections & Archives Program Manager, Atlas Systems, Inc.) commented
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.
-
Moira Fitzgerald commented
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?
-
Matthew Adair commented
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.
-
Moira Fitzgerald commented
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.
-
Matthew Adair commented
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.
-
Moira Fitzgerald commented
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.
-
Moira Fitzgerald commented
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
-
Genie Shropshire commented
How many fields are necessary and for what purpose?
-
Genie Shropshire commented
Would like to have more data fields to store information and for the data type to be specified (date, money, text, note, etc.)
-
Genie Shropshire commented
Sites would like to have more drop down fields on the request form that they can control the possible values.
-
Genie Shropshire commented
- 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.