Happy New Year everyone.
Our consortium has been on Tessitura for 18 years and lots of lists, extractions, and output sets (l/e/o) have been created by users at the various organizations during that time. Occasionally there has been some cleanup done by users, but many of the l/e/o remain in the system with a portion of those created by users who no longer work in the consortium. We have asked users to clean up and delete any old l/e/o, but we want to establish some clear guidelines for how long these are kept and have a regular procedure in place to reduce the number of outdated l/e/o.
At the Database Managers’ meeting last month, I posed this question and got some great feedback, such as having time limits for how long l/e/o are kept with periodic review (such as end of FY), naming conventions to easily identify evergreen items, reassigning l/e/o when a person leaves an organization. I also wanted to hear what others are doing to keep l/e/o from getting out of hand and if anyone has policies/guidelines in place.
Appreciate any feedback.
T.C.
So our l/e/o ( ) are a bit out of hand. We have a current project with the super user group that is
There are somethings that are business critical that we're putting a saftey fence around, and to be honest we need to back up the logic behind those things for safety
Part of our ongoing Data Strat's Hygiene plan is an annual LEO maintenance
Also that's a great point re: Nomenclature
The way I've dealt with the "save" ones in the past is to create a folder called "KEEP" or "MISSION CRITICAL" (or however you refer to them). If someone wants it saved, it's their responsibility to move them to that folder. Anything not in that folder is subject to the delete/deactivate rules. Also, I would check via SQL before doing the Delete/Deactivate to make sure the list wasn't referred to in another list or extraction. And if an output set was only referred to in a deleted/deactivated list, it could also be removed.
Do any of you use SQL to delete old extractions in bulk? We also have 17 years of old LEOs to grapple with.
I have used SQL to inactivate them, but you have to be more careful on the deletes due to referential integrity. At a minimum, you'd want to delete the detail rows (list contents) first. I'd also do a check of the catalog to see where else lists might be referenced in tables.
(I feel that - almost as many)
Maybe we can we talk about:
Thanks for the mention, Heath Wilder!
I'm happy to share my list/output set/extraction cleanup utility if anyone wants it. Email me at catherine@artsphilly.org and I'll send you a copy. It's currently good for v15. (We're still in early stages of v16 testing so I haven't yet checked it out there yet.)
The utility inactivates and/or deletes lists, output sets, and extractions that haven't been used in a specified amount of time. It's really helped our consortium keep those areas of Tess manageable, which, from an admin/backend perspective, is especially worthwhile when dealing with version upgrades.
Thanks Heath, Katie and Carol for sharing your ideas.
A few Ideas on this exist, but I've added a more comprehensive one (including links to the others):
community.tessituranetwork.com/.../better-management-for-old-lists-and-extractions-segmentations-and-output-sets