While I would love the ability to make changes at the database level using SQL, I can understand Innovative's reservations. We were on Symphony once before and I think they had SQL access gated behind some internal certification (I think there was a paid training or something...) and there was all kinds of language to make it clear the SirsiDynix would not be liable for any damages caused by library staff. I'm not sure I want to see Innovative go completely down that path, but I do think there needs to be some guardrails, given what's at stake. With that in mind, I think allowing SQL jobs/changes to be made from the Web Based System Admin would be a mistake. The consequences of a leaked password or other breach to an administrative page available on the open web are simply too high... I think this is something that should probably be locked to Remote Desktop access or similarly restricted to whitelisted IP addresses. So... maybe this doesn't require "Development" so much as it would require specific training/agreements between Innovative and library staff to allow write access to the existing RD SQL Database tools? Innovative may think that's too open though and need to find a way to restrict write access to certain tables or something...

I'll mention that RegEx support in the bulk change tools would take care of a great many of the potential database changes, including the UPPER() example mentioned... not trying to diminish this idea, but just some additional food for thought... I desperately miss the RegEx find/replace tool in SirsiDynix Data Control...

Currently when I need to make mass changes that aren't supported in any of bulk change options I have to do this on a one by one basis. Super time consuming to say the least. Also we wish to be able to schedule the batch updates instead of having to run these manually. Use Case: We need to be able to batch update patron registration information to all CAPs (makes it easier for staff to read). It's a relatively simple thing to do in SQL however I can't run the script for it. Another use case is staff on a regular basis don't edit the patron expiration date correctly based on patron code when a patron record is created. We currently have to do this manually, one by one, on a weekly schedule.

The ability to have some capacity to make changes via SQL is critical. One of the biggest issues we have faced since migrating a year and a half ago is the realization that we don't have any capacity to make large scale changes behind the scenes - something I did as needed in our old ILS (Symphony).