Hi all,
I'm not sure if this is an 'all Tessituras do this' or specific to our implementation. When a new account is created through our website, the new record's address is created twice and is modified by the WebAPI instantly, with the duplicate entry being inactivated. So, all new records from the website have an inactive duplicate of their mailing address.
For a while, a couple of us on the team would just update each record as they came in. Because we're kinda small, the volume isn't impractical, but this does mean we're spending time deleting something instead of doing something more productive. Does anyone know a setting or piece of code that is responsible for this that I could update in our system? This wouldn't replace real cleanup, but would be great at not needing to click into each and every new record.
Thanks!
Anthony
Opera Colorado
There's a setting for TNEW -- in T_DEFAULTS, I think -- that saves a copy of the address if the user makes a change on TNEW. So this is standard behavior if you have that option turned on. We have it turned on because otherwise if a patron updates their address on TNEW it will overwrite the existing address and you lose the old address. For us, we would rather have the duplicates come in at account creation and be assured that we have a history of addresses on the account. It comes up sometimes about where something was sent / when or why an address was changed. We find the extra level of detail useful.
We'd also prefer to maintain the old address. Thanks to you & Chris Jensen for pinpointing where that is. That's a really frustrating feature as it does clutter the database with completely redundant information.
Anthony Berkley said:That's a really frustrating feature as it does clutter the database with completely redundant information.
Amen.
Do you do much work in SQL Server? It would be pretty easy to set up a SQL Server Agent job to just delete any of these that have cropped up every night. Okay, not completely trivial: you'd need to clean up attached phones at the same time, but not too hard. Sounds like this would be a useful thing for a lot of TNEW users. I'd never heard of this setting (we don't have it on), and I'm actually going to discuss it with our departments (and organizations) in case they would like it turned on, as we do prefer to keep a record of people's past addresses.
I have a little SQL experience, but with something as significant as automatically update constituent data on an ongoing basis. I was honestly hoping someone else had this issue and they had written a solution to share, but I'll start looking into a process like you describe.
If you end up going this route... I think every SQL database person has their own semi-personalized database procedure for nightly clean-up. I just had a meeting with some internal people that reminded me that it has been a while since I looked at my own and need to update it. There are always certain business rules that preclude anything from being truly universal in this regard. What I will say there is that, as long as you keep it limited to things upon which you are confident, it can be highly effective at getting rid of "everyday issues".
For obvious reasons, do first in your TEST database. But doing so can definitely limit the number of complaints you get from your Box Office/people do actually do the manual clean-up.