I have moved into a role managing a V12 instance of Tessitura that has not moved over to the new standard ticket history table, and has not been customised to include owner/initiator/recipient roles. I'd be interested to see how other organisations who have maintained their custom ticket history tables have added the role data into the table, if anyone is willing to share their sql.
ThanksSarah
I have moved into a role managing a V12 instance of Tessitura that has not moved over to the new standard ticket history table, and has not been customised to include owner/initiator/recipient roles. I'd be interested to see how other organisations who have maintained their custom ticket history tables have added the role data into the table, if anyone is willing to share their sql. Thanks Sarah This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!
Thanks Sarah
Thanks everyone. Ken, look forward to seeing what you've got when you're back in town.
CheersSarah
Hi Sarah
I've posted the update script in my Files area here.
(plus our local ticket history table definition for v12, so you can see what it refers to)
There's a couple of local functions called in there - I presume your local tixhist won't need them, but I can add them in if you'd like to see what they do.
This was made in testing for v12.1 - It works for that version. It will need a small mod for v12.5, IIRC - that's what we're going to migrate to (real soon now...)
Ken
Unknown said: This was made in testing for v12.1 - It works for that version. It will need a small mod for v12.5, IIRC - that's what we're going to migrate to (real soon now...)
I'm curious - what mods to ticket history tables/tabs/etc. are needed specifically for v12.5?
Hi Chris
The logic I used creating our new LT_TICKET_HISTORY table for v12.1 was to take the new standard Tess ticket history table as a starting point, and tack our extra local fields on to the end - and then write the update script to populate the fields inherited from the standard version in the same way that Tess populates them - so that our table would be as similar to the Tess table as possible (a superset, in fact) and the diffs would be really clear.
In 12.5, there is a new field added to the Tess standard table, [rule_id] [INT] NULL, which holds a reference to the Rule which may have been activated in setting the price for that item (SLI, I suppose, actually). So to keep maximally consistent, I'll need to add that one into our local table as well, and borrow the appropriate code to populate it.
That's the only change, AFAIK - I haven't looked at that in detail yet, having been on leave for the last month, but I assume it'll be fairly straightforward - just grab the T_SUB_LINEITEM.rule_id value along with the other stuff, and then modify the custom screen stuff to show it (presumably translated into its description); and create List Elements and Output Set Elements to match.
Hi, Ken
Unknown said: The logic I used creating our new LT_TICKET_HISTORY table for v12.1 was to take the new standard Tess ticket history table as a starting point, and tack our extra local fields on to the end - and then write the update script to populate the fields inherited from the standard version in the same way that Tess populates them - so that our table would be as similar to the Tess table as possible (a superset, in fact) and the diffs would be really clear.
Great, I did the same: literally started with a "script table as CREATE to" and added my custom columns.
Unknown said: In 12.5, there is a new field added to the Tess standard table, [rule_id] [INT] NULL, which holds a reference to the Rule which may have been activated in setting the price for that item (SLI, I suppose, actually). So to keep maximally consistent, I'll need to add that one into our local table as well, and borrow the appropriate code to populate it.
Good to know. I'll definitely add column and code for that as well.
Thanks for the details...