Hi all,
After building the 2010 season I've been told that one of the shows dates has changed by two weeks, is there any reason not to simply run an update like this example?
update t_perfset perf_dt = dateadd(dd,-14,perf_dt)from t_perf where prod_season_no = ???
I don't think it matters but these shows have not been seated yet but are built into performance groups and packages.
Thanks!
You can directly change the date on a performance in the application at any time, whether tickets have been sold or not. You don’t need to do it through SQL Server. The date is not the ID of a performance, just another piece of descriptive information. If tickets had been sold, then the only problem you might have is that the date printed on the tickets before the change would be wrong so you would want to reprint the tickets.
As far as packages go, it shouldn’t be a problem as long as the performance should still be a part of whatever packages it is a part of. If the date change means that the performance should now be in a different package, then you will have to remake and resell your packages.
Kevin Sheehan
Documentation & Learning Resources Specialist
Tessitura Network
1 888 643 5778 ext 329 Office
ksheehan@tessituranetwork.com
Thanks Kevin, I'm aware that I can do so via the application itself and that this is always going to be the recommended approach but I was just curious if there was any reason other than that to not do so via SQL.
I've got about 40 perfs to update and even though I know it wont take that long I feel like doing this one at a time will increase the chance for error on my part.
One issue I've run into doing this is forgetting about MOSs, pts, web publish dates being relative to the perf date from the original setup. So when you just change the perf dates, you may end up with modes of sale and price types ending two weeks earlier than intended. So you probably want to update your various end dates as well.
Somehow I missed that you were looking to save time using SQL. In that case, I’m not sure of any caveats. I’m not an expert on the database side of the system. It seems like it should be o.k. Definitely try it in your Test system first, and maybe open a help ticket so those wiser than I in this area can weigh in on anything to look out for.
ooh, good one Amanda!My price types & web publish dates are usually open ended but good call about all those things.I think unless someone tosses up a red flag I'll do the update on perf_dt but do the MOS in season mgr.
Thanks Kevin and Amanda for the feedback!
Ryan -
I do this all the time. I know you posted this a long time ago (catching up on my forum posts *finally*), but just to let you know that besides the noted start/end dates, the only other dates I watch out for are on calendar/on web dates as well.
One other thing I watch for on my implementation is any "funny" shows (i.e. dummy perfs that we have set to an outlying date). These are normally a set date and I don't want to bump them forward.
- Heather
One other thought is source code end dates if you have anything using a special source.
Thanks everyone!
Thankfully these were freshly created shows so there wasn't much that needed updating but this thread and all the input will come in handy again I'm sure.
Cheers!